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PREFACE 


This  Memorandum  describes  s  computer  model  for  simulating  s  com¬ 
posite  of  operstions  and  support  functions  at  an  Air  Force  base. 
Identified  as  the  Logistics  Composite  Model  (L-COM) ,  its  development 
has  been  a  joint  effort  of  personnel  at  Headquarters,  Air  Force 
Logistics  Command ,  and  The  RAND  Corporation. 

Presented  here  is  an  overall  description  of  the  model  and  Its 
use.  Separate  reference  manuals  will  describe  technical  details 
concerning  input  data  preparation,  program  logic,  and  interpretation 
of  outputs . 

Captain  R.  R.  Fisher,  W.  W.  Drake,  and  J*  J.  Delfausae  were  with 
the  Air  Force  Logistics  Command  when  this  research  was  performed. 

A.  J.  Clark  and  A.  L.  Buchanan  are  with  The  RAND  Corporation.  Mr. 
Clark  is  a  consultant. 
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Thia  Memorandum  deacrlbea  a  model  for  aimulaCing  overall  opera- 
tio re  and  support  functions  at  an  Air  Force  base.  Identified  as  the 
Logistics  Composite  Model  (L-COM) ,  it  is  applicable  to  a  variety  of 
planning  studies  concerned  with  base  level  functions.  The  description 
la  oriented  toward  how  the  operational  environment  is  represented, 
what  decision  processes  are  Included,  and  how  the  model  may  be  used 
in  various  kinds  of  planning  studies. 

L-OOM  consists  of  three  main  programs:  a  preprocessor,  a  simu¬ 
lation  program,  and  a  postprocessor.  The  preprocessor  translates 
data  provided  on  specialized  forms  designed  for  user  convenience  into 
data  forma  the  simulation  program  requires.  It  also  generates  sortie 
requirements  in  accordance  with  a  specified  flying  program. 

The  slmulaticn  program,  driven  by  data  from  the  preprocessor, 
represents  flight  and  base  support  processes  in  response  to  mission 
requirements.  The  logic  of  the  model  replicates  the  flying  of  air¬ 
craft;  the  accomplishment  of  servicing  tasks  such  as  refueling  and 
weapons  loading;  the  incurrence  of  malfunctions;  the  accomplishment 
of  flight-line  aircraft  maintenance;  the  repair  of  components  in 
base  repair  shops;  the  utilization  and  interaction  of  resources  in 
the  demand  process;  the  changes  in  resource  availability  according  to 
shift  policies;  and  other  facets  of  the  overall  base  operation. 

As  the  simulation  program  operates ,  it  presents  results  in  a 
periodic  performance  summary  report.  At  the  user's  option,  the  pro¬ 
gram  may  produce  several  kinds  of  status  reports.  Using  results  of 
the  simulation,  the  postprocessor  presents  summary  statistics  in 
graphical  fora  and,  for  selected  aircraft,  displays  of  the  processes 
Incurred  by  the  airplane  and  components  removed  for  shop  repair. 

In  normal  operation,  the  preprocessor  is  first  used  to  develop 
a  data  base  for  the  simulation.  The  simulation  program  may  then  be 
run  many  times,  with  systematic  changes  being  made  in  the  data  base 
according  to  particular  study  objectives.  The  postprocessor  may  be 
used  after  each  simulation  to  provide  results  in  a  form  convenient 
for  analysis. 
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The  model  hu  two  unique  festures.  One  is  the  task  network  that 
describes  base  processes  to  be  simulated  by  identifying  particular 
tasks  and  the  sequence  for  accomplishing  them.  Input  data  prescribe 
durations  arid  resource  requirements  for  each  task.  By  providing  net¬ 
work  and  related  data,  the  user  exercises  direct  control  over  the 
environmental  representation  Included  in  the  simulation. 

The  other  unique  feature  consists  of  embedded  decision  routines 
that  help  determine  a  best  mix  of  resources  to  support  a  prescribed 
flying  program.  During  a  simulation,  these  routines  determine  whether 
given  performance  goals  are  being  met  and,  if  not,  the  routines  use 
a  cost-effectiveness  criterion  to  augment  resource  levels  selectively 
until  desired  performance  objectives  are  attained. 

The  model  requires  a  computer  with  an  internal  memory  of  at  least 
65,000  words  of  36-bit  length  or  equivalent.  A  typical  problem  re¬ 
quires  from  1-1/2  to  2  minutes  of  computer  time  to  simulate  a  day's 
worth  of  base  operations  involving  1500  different  tasks.  Since  the 
modal  is  written  in  SXMSCRlPl,  almost  any  computer  of  sufficient  size 
may  be  used. 

To  validate  L-C0M,  it  is  planned  to  use  data  and  experience 
gained  from  APLC  Project  PACER  SORT.  Results  from  both  the  model  and 
the  field  test  will  be  compared  for  a  number  of  key  performance  measures. 
If  a  sufficiently  close  match  is  obtained,  the  model  may  be  used  with 
Increased  confidence  for  other  applications. 

Several  extensions  and  refinements  are  planned  for  L-C0M.  A 
repair-level  decision  model  is  being  developed  to  enable  initial 
determinations  of  repair  policies  and  associated  resource  requirements. 
The  simulation  program  may  be  extended  to  include  representations  of 
conflicting  and  defined  maintenance,  shop  cannibalization,  weather 
effects,  and  multibase  operat  as.  The  embedded  decision  processes 
may  also  be  refined  in  several  ways,  finally,  data  bank  and  on-line 
simulation  concepts  say  be  employed  to  facilitate  the  use  of  the  model 
in  some  planning  studies. 

Present  and  future  versions  of  L-C0M  should  have  significance 
for  logistics  requirements  studies  in  support  of  contingency  deploy¬ 
ments  end  determinations  of  preferred  repair  policies,  as  well  as 
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associated  resource  requirements  studies  for  weapon  systems  being 
designed.  In  addition,  the  model  may  be  used  in  any  problem  involving 
appreciable  interaction  among  the  many  functions  accomplished  at  an 
Air  Force  base. 
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I ■  INTRODUCTION 


From  management ' s  point  of  view ,  the  operation  of  an  Air  Force 
baae  encompaaaea  moat  of  the  functlona  of  a  large  buaineaa  aa  well  aa 
thoae  of  a  military  organization.  Included,  in  particular,  are  plan¬ 
ning  functlona  concerned  with  the  acquisition  and  efficient  use  of 
the  many  kinds  of  reaourcea  involved  in  baae  operatlona.  Due  to  the 
complex  interrelationahipa  that  exist  in  using  resource  mixes  to 
accomplish  a  variety  of  mission  requirements,  planning  studies  of 
significant  scope  have  been  very  difficult  to  perform.  To  help  alle¬ 
viate  this  difficulty,  several  kinds  of  computer-based  analysis  techniques 
have  been  developed  in  recent  years.  One  considerably  important  tech¬ 
nique  is  simulation — the  representation  of  base  functions  in  terms  of 
a  model  of  the  environment. 

In  general,  computerized  simulation  models  enable  a  planner  to 
visualize  how  a  baae  operates  under  actual  or  postulated  conditions 
without  disturbing  the  operation  of  the  baae  itself.  Such  a  model 
serves  as  a  kind  of  laboratory  In  which  an  analyst  can  experiment  with 
and  try  out  new  concepts  governing  base  operations  and  resource  utili¬ 
zation.  It  enables  him  to  determine  how  baae  processes  are  inter¬ 
related  and  affected  by  postulated  changes  in  the  way  they  are  accom¬ 
plished.  By  this  means,  preferred  solutions  to  base  management  problems 
may  be  determined,  together  with  estimates  of  accrued  benefits  upon 
implementation. 

This  Memorandum  describes  a  model  for  simulating  overall  baae 
operations  and  logistical  support  functions.  Identified  as  the 
Logistics  Composite  Model  (L-COM) ,  it  is  applicable  to  many  planning 
studies  concerned  with  base- level  functions.  The  description  is 
oriented  toward  how  the  operational  environment  is  represented,  what 
decision  processes  are  included,  and  how  the  model  may  be  used  in 
varloua  kinds  of  planning  studies. 

BACKGROUND 

In  the  past  several  years,  a  number  of  simulation  models  addressed 
to  weapon  system  operation  and  support  at  Air  Force  bases  have  been 
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con« true ted.  Each  model  has  design  characteristics  that  facilitate 

I 

and  usually  constrain  its  use  to  particular  classes  of  study  objec¬ 
tives.  In  general,  these  distinguishing  features  are  the  way  of 
representing  the  base  environment  and  the  level  of  detail  in  simula¬ 
ting  various  base  functions  such  as  operations,  maintenance,  and 
supply.  Technically,  the  models  are  further  distinguished  by  the 
kinds  of  input  data  required,  the  language  in  which  the  computer 
programs  are  written,  the  kinds  of  computers  upon  which  the  models 
can  operate,  and  the  types  of  output  reports  produced. 

The  Logistics  Composite  Model  was  also  developed  to  address  a 
particular  class  of  study  objectives — that  associated  with  Project 
PACER  SORT  (formerly.  Project  LOG GY  SORT).  This  project,  sponsored 
by  the  Air  Force  Logistics  Command,  concerned  the  test  and  evaluation 
of  revised  repair  and  maintenance  policies  to  support  tactical  air¬ 
craft  in  both  peacetime  and  contingency  operations.  The  main  project 
objective  was  to  determine,  from  a  cost-effectiveness  point  of  view, 
the  best  mix  of  base  and  depot  level  repair,  with  associated  require¬ 
ments  for  maintenance  personnel,  ground  support  equipment,  repair 
parts,  transportation,  communications  and  other  supporting  resources. 

To  accomplish  part  of  the  project  objectives,  a  field  test  was 
conducted  in  South  Vietnam  during  the  first  six  months  of  1967.  The 
test  Involved  the  support,  under  combat  conditions,  of  two  squadrons 
of  F-4C  aircraft  with  a  greater  degree  of  depot  level  repair  of  com¬ 
ponents  than  prescribed  by  previous  maintenance  policies.  Included 
in  the  test  was  a  control  group  of  two  other  squadrons  operating  with 
aisdlar  mission  requirements  but  supported  by  extensive  amounts  of 
base  repair  according  to  traditional  policies.  A  comprehensive  data 
collection  program  was  used  to  measure  and  evaluate  the  effects  of 
the  two  maintenance  concepts  upon  operations  and  overall  logistics 


Three  such  models  have  been  developed  at  The  RAND  Corporation. 
They  are  described  in  the  following:  A.  S.  Ginsberg  and  B.  A.  King, 
Base  Operations -Maintenance  Simulator ,  The  RAND  Corporation,  RM-4Q72, 
August  1964;  T.  C.  Smith,  SAMSOM:  Support-Availability  Multi-System 
Operations  Model,  The  RAND  Corporation,  RM-4077-PR,  June  1964;  and 
B.  J.  Voosen,  PLANET:  Planned  Logistics  Analysis  and  Evaluation 
Technique,  The  RAND  Corporation,  RM-4950-PR,  January  1967, 


support.  Results  of  the  test  experience  ere  contained  In  a  final 

* 

report  published  on  30  June  1967. 

From  the  start  of  Project  PACER  SORT,  a  number  of  limitations  of 
the  field  test  in  satisfying  the  basic  study  objectives  were  recognized. 
First,  the  test  involved  F-4C  aircraft  whose  supporting  resources 
(such  as  ACE — aerospace  ground  equipment — and  repair  parts)  had  already 
been  designed  and  procured  under  previous  maintenance  concepts  of 
maximum  base  self-sufficiency;  this  severely  constrained  possible 
changes  in  repair  policies  and  largely  prevented  any  savings  in  cost 
and/or  increases  in  operational  effectiveness.  Second,  data  collected 
from  the  field  test  represented  che  operation  of  a  particular  type  of 
aircraft  in  a  particular  operational  and  management  environment.  The 
usefulness  of  this  data  and  its  results  for  other  types  of  aircraft 
operating  in  ocher  environments  and  in  future  time  frames  was  doubtful. 
Third,  due  to  the  size,  complexity,  and  limited  duration  of  the  field 
test,  it  was  realistically  impossible  to  test  and  evaluate  gradations 
in  repair  level  policies,  thereby  precluding  the  determination  of  the 
best  mix  of  base  and  depot  level  repair. 

To  overcome  these  limitations  and  others,  simulation  was  accepted 
as  a  means  for  augmenting  and  extending  the  field  test  results.  We 
hoped  that  a  simulation  model  could  not  only  replicate  the  field  test 
environment  in  order  to  extend  test  results  over  longer  operational 
time  periods,  but  also  apply  to  other  aircraft,  operational  and  logis¬ 
tical  support  environments,  postulated  maintenance  and  supply  policies, 
and  conditions  prevailing  in  current  and  future  time  frames  not  en¬ 
compassed  by  the  field  test  itself.  In  general,  a  simulation  model 
would  accomplish  many  of  the  study  objectives  without  incurring  the 
considerable  expenses  for  the  variety  of  field  tests  that  would  other¬ 
wise  be  indicated. 

So  a  team  of  analysts  and  programmers  was  established  to  develop 
a  simulation  model  for  the  PACER  SORT  project.  The  team,  consisting 
of  personnel  from  AFLC  and  The  RAND  Corporation,  began  the  development 


* 

Project  PACER  SORT  Special  Overseas  Repair  Test ,  Final  Report, 
Headquarters  Air  Force  Logistics  Command  (67  MCGF-106) . 
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effort  at  RAND  In  November  1966.  In  March  1967,  the  program  was 
transferred  to  Headquarters  AFLC  in  Dayton,  Ohio,  to  take  advantage 
of  the  larger  capacity  of  its  UNIVAC  1107  computer.  The  Logistics 
Composite  Model  described  here  is  the  result  of  the  joint  AFLC-RAND 
development  program. 

SCOPE 

Essentially,  the  current  L-COM  model  (MOD  1)  can  simulate  a 
composite  of  aircraft  operations  and  main  supporting  functions  at  one 
Air  Force  base.  In  particular,  it  contains  representations  of  flying 
operations  for  a  mix  of  aircraft  and  sortie  types,  flight-line  and 
shop  repair  processes  for  both  aircraft  and  components,  and  supply 
functions  in  support  of  maintenance.  Classes  of  resources  explicitly 
identified  (by  line  item  within  each  class)  in  the  model  include  air¬ 
craft,  personnel,  spare  parts,  AGE,  and  facilities.  In  general, 

L-COM  permits  representations  of  all  basic  functions  involved  in 
aircraft  operations  and  support  in  varying  levels  of  detail  as  pre¬ 
scribed  by  the  user. 

With  minor  programming  changes,  particularly  in  the  output  re¬ 
port  formats,  the  model  can  simulate  a  missile  weapon  system  deployed 
in  a  region  but  subject  to  common  support.  With  other  changes,  it 
can  simulate  the  operation  of  a  depot  repair  and  overhaul  facility. 

To  apply  the  model  in  these  and  other  areas,  the  user  must  develop 
corresponding  input  data  and  make  appropriate  alterations  in  the  out¬ 
put  reports . 

Aside  from  simulating  base  operations,  the  model  contains  decision 
logic  for  determining  which  resource  items  are  degrading  system  per¬ 
formance  the  most,  and  determining  how  much  to  increase  these  item 
levels  to  maintain  a  prescribed  effectiveness.  The  use  of  this  logic 
for  a  given  model  run  is  at  the  user's  discretion.  Except  for  this 
logic,  there  is  no  representation  of  supply  replenishment  policies 
other  than  a  one-for-one  replacement  of  items  lost  to  the  base 
through  condemnation  or  return  to  depot. 
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OVERALL  STRUCTURE 

The  Logistics  Composite  Model  (MOD  1)  consists  of  three  main  com¬ 
puter  programs:  a  preprocessor,  a  simulation  model,  and  a  post¬ 
processor.  Figure  1  shows  how  these  programs  interrelate  in  the  over¬ 
all  operation  of  the  model. 

The  preprocessing  or  input  program  has  two  functions: 

1.  It  serves  as  a  translator  to  reduce  or  reformat  data 
provided  on  specialized  forms  designed  for  user  con¬ 
venience  into  data  forms  required  by  the  simulation 
model. 

2.  It  generates  sortie  requirements  for  a  flying  program 
specified  by  the  user,  who  defines  the  requirements 
in  terms  of  missions,  with  varying  numbers  of  sorties 
per  mission,  to  be  accomplished  at  specified  times 

in  the  simulation. 

In  translating  user-provided  data  into  formats  required  by  the  simula¬ 
tion  model,  the  preprocessor  edits  the  data  for  errors  and  complete¬ 
ness.  When  the  preprocessor  detects  errors  or  inconsistencies,  it 
prints  appropriate  error  messages.  In  some  cases  where  ambiguities 
are  found,  assumptions  are  made  about  what  the  user  intended,  and  a 
message  is  provided  about  what  was  found  and  what  assumption  was  made. 
In  more  serious  cases,  where  such  an  assumption  cannot  be  made,  further 
processing  la  discontinued  until  the  omission  is  corrected. 

The  preprocessor  outputs  two  classes  of  data.  The  first  class 
(initialization  data)  describes  the  environment  to  be  simulated  and 
prescribes  initial  values  for  resource  levels,  reliability  factors, 
policy  parameters,  and  other  elements.  The  second  class  (exogenous 
events)  describes  mission  requirements  in  terms  of  takecff  times, 
number  of  airplanes  needed,  types  of  sorties,  and  other  data  per¬ 
taining  to  the  missions. 

Driven  and  controlled  by  data  from  the  input  program,  the  simula¬ 
tion  model  provides  a  representation  of  flight  and  base  support  pro¬ 
cesses  in  response  to  mission  requirements.  The  logic  of  the  model 
replicates  the  flying  of  aircraft;  the  accomplishment  of  servicing 
tasks  such  as  refueling,  weapons  loading,  etc.;  the  incurrence  of 
malfunctions;  the  accomplishment  of  flight-line  aircraft  maintenance; 


—  Overall  structure  of  the  Logistics  Composite  Model  (MOD  1) 


the  repair  of  components  in  base  repair  shops;  the  utilization  and 
interaction  of  resources  in  the  demand  process;  changes  in  resource 
availability  according  to  shift  policies;  and  other  faceta  of  the 
overall  base  operation. 

In  general,  user-provided  input  data  determine  the  degree  of 
detail  for  base  processes.  The  processes  and  the  way  they  Interrelate 
are  described  in  task  networks,  which  identify  the  processes  that  can 
be  done  in  parallel  (simultaneously)  and  those  that  must  be  accom¬ 
plished  sequentially.  For  each  network  process  or  task,  the  user 
provides  data  determining  the  task  duration  and  required  kinds  and 
amounts  of  resources.  By  so  doing,  he  exercises  direct  control  over 
the  environment  represented  in  the  simulation. 

The  model  presents  the  resources  used  in  base  processes  in  terms 
of  specific  identifications  the  user  provides.  For  example,  the  user 
nay  specify  several  aircraft  types,  several  dozen  types  of  maintenance 
personnel,  perhaps  a  hundred  different  kinds  of  Aerospace  Ground 
Equipment,  and  several  hundred  kinds  of  spare  parts;  the  resource 
mix  and  the  total  resources  included  are  constrained  only  by  computer 
capacity.  For  each  identified  resource,  the  model  keeps  track  of 
the  amount  available,  amount  in  use,  amount  due-out,  and  so  forth  in 
accordance  with  resource  interactions  in  accomplishing  support  re¬ 
quirements  during  the  simulation. 

While  a  simulation  is  in  progress,  the  user  may  apply  embedded 
decision  routines.  These  determine  whether  specified  performance 
goals  are  being  met  and,  if  not,  selectively  augment  resource  levels, 
according  to  a  cost-effectiveness  criterion,  until  the  desired  per¬ 
formance  objectives  are  attained.  The  main  output  of  the  simulation 
model  is  a  performance  summary  report  produced  at  specified  intervals 
during  the  simulation.  This  report  presents  susnary  statistics  in 
six  functional  categories:  operations,  aircraft,  personnel,  shop 
repair,  supply,  and  equipment.  Consolidating  model  results  in  one 
report  helps  discern  the  interactions  of  the  functional  support  areas 
in  response  to  mission  requirements.  In  addition  to  this  report,  the 
model  provides,  at  user-option,  separate  statue  reports  for  resources, 
missions,  Jobs  in  process,  and  jobs  back-ordered  at  specified  simula¬ 
tion  times. 
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Uaing  data  produced  by  the  nain  simulation  model,  the  postprocessor 
gives  the  user  two  kinds  of  products.  One  consists  of  the  same  data 
contained  in  the  performance  summary  report  but  presented  In  graphical 
form.  Thus  It  provides  plots  of  fill  rates,  aircraft  utilization, 
personnel  utilization,  and  other  suaaary  results  over  simulated  time, 
each  on  a  separate  page.  The  second  product  consists  of  graphical 
displays  for  selected  airplanes.  Each  display  identifies  the  pro¬ 
cesses  incurred  and  the  time-in-process  for  both  the  aircraft  and  com¬ 
ponents  removed  from  the  aircraft  for  shop  repair.  The  production  of 
either  or  both  products  of  the  postprocessor  is  optional  in  any  given 
run. 

For  normal  operation  of  the  overall  model,  the  preprocessor  is 
first  run  to  obtain  a  data  base  for  the  simulation.  Then  a  number  of 
simulation  runs  are  made  changing  certain  variables  between  runs  as 
needed  for  particular  study  objectives.  The  postprocessor  may  or  may 
not  be  exercised  for  each  run,  again  depending  upon  the  study  objec¬ 
tives.  Run  results  are  then  consolidated,  compared,  evaluated,  and 
analyzed.  For  large  studies,  this  mode  of  operation  may  be  repeated 
several  times,  using  a  significantly  different  data  base  for  each  set 
of  runs . 

APPLICATION  AREAS 

The  main  application  of  the  Logistics  Composite  Model  is  the 
analysis  of  alternative  repair  policies .  The  model  is  uniquely 
structured  for  such  studies,  since  it  can  rapresent  different  kinds 
of  repair  processes  by  means  of  input  data  only  rather  than  by  changes 
in  the  computer  programs.  Thus  L-COM  can  analyze  any  postulated 
repair  policy,  with  corresponding  variations  in  the  repair  processes 
involved. 

Because  of  the  flexibility  built  into  the  model  for  repair-level 
analyses,  it  may  also  be  used  for  many  studies  concerning  overall  base 
operations;  in  particular,  because  it  can  explicitly  represent  many 
specific  resources,  it  can  perform  studies  involving  resource  alloca¬ 
tion  and  utilization.  For  example,  L-OOM  can  analyze  alternative 


policies  for  stocking  reparable  spares,  allocating  aaintenance  per¬ 
sonnel  across  shifts,  providing  ground  support  equipnent,  and  so 
forth.  Using  the  model  for  these  kinds  of  analyses  allows  the  analyst 
to  measure  the  overall  effects  upon  mission  performance  as  well  as 
functional  interactions. 

Another  application  area  is  the  determination  of  support  require¬ 
ments  for  alternative  flying  programs.  First,  the  model  may  be  used 
to  measure  the  adequacy  of  a  given  resource  mix  to  support  different 
flying  programs,  either  under  steady-state  conditions  as  for  a  peace¬ 
time  training  program  or  in  a  dynamic  environment  as  for  support  of 
a  contingency  operation.  This  helps  determine  how  support  limitations 
affect  flying  programs.  Second,  the  model  may  assist  in  determining 
a  preferred  mix  of  resources  to  support  a  given  set  of  flying  programs. 
For  these  analyses,  the  decision  routines  are  particularly  valuable 
since  they  identify  limiting  resources  and  provide  guidance  regarding 
how  much  augmentation  they  need  to  sustain  an  acceptable  level  of 
mission  effectiveness. 

Another  major  application  area  is  the  determination  of  logistics 
support  requirements  for  airplanes  being  designed  and  the  investiga¬ 
tion  of  the  logistical  consequences  of  alternative  designs  for  air¬ 
craft  components  and  ground  support  equipment.  Provided  for  this 
application  are  engineering  estimates  for  reliability  factors,  repair 
processes  involved,  and  other  portions  of  the  input  data.  The  model 
can  vary,  from  one  component  to  another,  the  level  of  detail  in  which 
repair  processes  are  represented.  Thus,  for  particular  components 
subject  to  design  evaluation,  greater  detail  can  be  included  for  more 
precise  measurements  concerning  Che  utilization  of  maintenance  per¬ 
sonnel,  AGE,  spares,  and  other  resources,  as  veil  as  the  effects  upon 
overall  weapon  aystea  performance. 

With  slight  modifications,  the  L-COM  model  may  be  applied  in  a 
number  of  other  areas.  In  principle,  it  can  be  applied  wherever  the 
environment  can  be  represented  as  a  task  network  with  each  task  re¬ 
quiring  time  and/or  resources  of  specified  kinds.  The  kinds  of  pro¬ 
cesses  that  the  task  network  structure  can  accomodate  will  be  de¬ 
scribed  in  detail  in  Sec.  II. 
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LANGUAGE 

Th«  computer  programs  for  the  Logistics  Composite  Model  have 

* 

been  vritten  in  SIMSCRIPT,  which  seems  the  most  appropriate  language 
for  a  simulation  model  of  this  size  and  scope.  In  particular,  the 
dynastic  storage  allocation  and  initialization  features  of  the  language 
enable  the  use  of  the  model  for  large  problems.  Other  features  of 
the  language  facilitate  the  structuring  of  the  model  and  the  program¬ 
ming  effort. 

Since  this  report  is  oriented  toward  an  overall  description  of 
the  model  and  the  logical  processes  that  it  contains ,  references  to 
particular  terminology  of  the  SIMSCRIPT  programming  language  will  be 
kept  to  a  minimum.  Where  necessary,  however,  such  terms  will  be 
defined  in  context  with  their  use  in  the  text. 

CONTENTS 

The  foundation  and  main  distinguishing  feature  of  the  Logistics 
Composite  Model  is  the  concept  of  representing  the  environment  as 
task  networks.  Because  of  its  importance,  this  concept  is  described 
In  some  detail  In  the  next  section.  Following  this,  the  model  itself 
Is  described,  with  separate  sections  being  devoted  to  the  separate 
prograas  Included  in  the  overall  model. 

Section  VII  gives  several  operating  characteristics  of  the  model 
such  as  the  size  of  problems  it  can  accept  and  the  computer  time  re¬ 
quired  to  operate  it.  Section  VIII  discusses  the  validation  require¬ 
ments  of  the  model  and  a  brief  summary  of  validation  experience  in 
context  with  the  PACER  SORT  project.  Finally,  Sec.  IX  describes  plans 
for  future  extensions  and  refinements  of  the  model. 

Two  appendixes  are  included.  One  contains  a  list  of  data  ele¬ 
ments  that  the  user  provides  to  the  model.  The  other  contains  a 
summary  description  of  the  major  subroutines  Included  in  the  main 
simulation  model;  similar  descriptions  for  the  pre-  and  postprocessors 
are  omitted . 

*H.  M.  Markowitz,  B.  Hausner,  and  H.  W.  Karr,  SIMSCRIPT:  A 
Simulation  Programing  Language,  The  RAND  Corporation,  RM-3310-PR, 
November  1962. 
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OTHER  DOCUMENTATION 

Several  other  documents  pertaining  to  L-COM  are  being  prepared  or 
planned.  Included  are  the  following:  Summary  Report;  User's  Reference 
Manual;  Programmer 'a  Reference  Manual. 

The  Summary  Report  consists  of  brief,  overall  descriptions  of  the 
model  and  its  potential  use  in  planning  studies.  The  User's  Reference 
Manual  contains  detailed  specifications  for  developing  input  data, 
descriptions  of  logical  processes  included  in  the  model,  descriptions 
and  examples  of  output  reports,  procedures  for  running  the  model  on  a 
computer,  and  general  guidance  concerning  the  use  of  the  model  in  par¬ 
ticular  application  areas.  The  Programmer's  Reference  Manual  contains 
a  detailed  narrative  description  of  the  computer  programs  for  the 
model,  as  well  as  the  SIKSCRIPT  program  listings.  These  three  docu¬ 
ments  are  being  prepared  by  personnel  in  the  Simulation  Center  at 
Headquarters  APLC. 

In  addition  to  the  above,  it  is  anticipated  that  a  series  of 
reports  describing  the  application  and  results  of  the  model  in  con¬ 
text  with  particular  studies  will  be  produced.  These  will  probably 
be  developed  by  organizations  and  study  groups  uaing  the  model. 


II.  TASK  NETWORKS 


The  mein  feature  and  unique  characteristic  of  the  Logistics 
Composite  Model  is  the  way  the  support  environment  can  be  represented 
in  the  model  logic.  This  representation,  consisting  of  task  networks 
developed  by  the  user,  constitutes  the  foundation  of  the  model  and 
provides  the  flexibility  needed  to  explore  many  problem  areas.  Thi3 
section  describes  the  task  network  concept  in  some  detail;  later 
sections  show  how  the  technique  is  used  in  the  overall  simulation. 

GENERAL  CONCEPT 

The  basic  idea  of  the  task  network  approach  is  that  all  processes 
in  the  environment  can  be  expressed  in  network  form,  as  illustrated 
in  Fig.  2.  In  fact,  the  first  thing  an  L-COM  user  must  do  is  construct 
such  a  network  for  the  processes  he  wishes  to  simulate. 

The  network  consists  of  lines,  representing  separately  identified 
tasks,  and  circles  (or  nodes),  representing  the  start  and  completion 
of  tasks.  In  general,  tasks  are  defined  as  processes  or  operations 
that  require,  for  their  accomplishment,  certain  lengths  of  time  and 
specified  types  and  amounts  of  resources.  Tasks  that  might  be  iden¬ 
tified  to  represent  aircraft  support  functions  at  a  base  are  as  follows 

Airplane  flight; 

Airplane  refueling; 

Weapons  loading ; 

Flight-line  check  of  a  component ; 

Flight-line  repair  of  a  component; 

Flight-line  removal  and  replacement  of  a  component; 

Bench-check  of  a  component  in  a  repair  shop; 

Repair  of  a  component  in  a  repair  shop; 

Obtaining  a  spare  part  from  base  supply; 

Transportation  of  spare  part  to  the  flight-line; 

Replacing  a  spare  part  from  depot  supply. 

These  tasks,  which  only  represent  those  the  user  may  define,  all 
require  time  and  resources. 
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In  addition  to  identifying  all  of  the  processes  to  be  simulated, 
the  network  Indicates  how  they  interrelate  in  terms  of  sequence  of 
accomplishment.  As  indicated  in  Fig.  2,  some  tasks  must  be  performed 
in  strict  sequence;  others  may  be  performed  simultaneously  or  in 
parallel.  In  some  cases,  a  task  cannot  be  started  until  a  number  of 
earlier  parallel  tasks  have  all  been  completed. 

Even  though  the  network  identifies  all  possible  tasks  includes 
in  the  simulation,  not  all  of  them  will  necessarily  be  incurred  in  a 
particular  instance.  Suppose,  for  example,  that  an  airplane  is  ex¬ 
posed  to  the  processes  shown  in  Fig.  2  involving  preflight  tasks,  the 
flight  itself  (considered  as  a  task),  and  various  postflight  tasks. 

Some  of  these,  such  as  refueling  and  the  flight  itself,  must  always 
be  incurred.  Others,  such  as  unscheduled  maintenance  after  the  flight, 
may  or  may  not  be  incurred;  the  selection  is  subject  to  chance  or 
the  probability  of  system  failure  during  the  flight.  As  described 
later,  simple  conventions  have  been  established  to  identify  which 
tasks  will  happen  with  certainty,  and  which  will  occur  by  chance  as 
the  simulation  progresses. 

During  simulation,  the  task  network  is  applied  to  a  number  of 
airplanes  simultaneously.  At  a  particular  instant  of  time,  one  air¬ 
plane  may  be  in  the  fueling  task,  another  may  be  in  the  flight  task, 
others  may  be  in  various  kinds  of  unscheduled  maintenance  tasks,  and 
so  forth.  The  simulation  model  keeps  track  of  each  airplane  and 
where  it  is  in  the  network.  It  also  selects  which  tasks  each  airplane 
will  undergo,  according  to  occurrence  probabilities  based  upon  com¬ 
ponent  reliability  data  and  other  factors. 

Portions  of  the  task  network  may  represent  shop  repair  processes 
for  components  removed  from  aircraft.  For  these  components,  the  pro¬ 
cessing  is  similar  to  that  for  airplanes.  The  model  keeps  track  of 
each  component  as  a  separate  entity  and  selects  appropriate  tasks  in¬ 
volved  in  the  repair.  During  repair,  assemblies  may  be  removed  from 
the  component  (as  indicated  by  corresponding  tasks  in  the  network) 
and  undergo  separate  processing.  Again,  the  model  tracks  each  assembly 
through  its  portion  of  the  overall  network.  There  Is  no  logical  limi¬ 
tation  on  the  detail  of  component  breakouts  of  this  kind;  the  only 
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limitations  are  the  user's  ability  to  describe  the  processes  involved 
in  network  form  and  the  comnuter's  storage  capacity. 

In  general,  describing  the  environment  to  be  simulated  in  task 
network  form  enables  the  user  to  specify  any  degree  of  detail  or  com¬ 
plexity  that  he  finds  necessary  for  his  study  objectives.  An  addi¬ 
tional  feature  permits  the  network  to  be  designed  in  sections,  thereby 
simplifying  and  reducing  the  input  data  required.  Thus  a  separate 
section  which  is  utilized  in  more  than  one  place  in  the  total  network 
can  be  defined  only  once  and  called  from  several  locations  within  the 
network.  Ar»  example  of  this  might  be  maintenance  actions  applicable 
to  both  pre-  and  postflight  phases  of  the  airplane  operation.  There 
is  no  limit  on  the  number  or  size  of  these  sections.  This  feature, 
as  well  as  other  characteristics  of  the  network  formulation,  are 
further  described  below. 

TYPES  OF  TASKS 

In  developing  a  task  network,  each  task  must  be  ssslgned  a  unique 
name  and  all  except  the  terminal  nodes  must  be  numbered  or  lettered 
in  some  fashion.  The  only  restriction  on  how  tasks  and  nodes  are 
labeled  is  that  they  must  be  uniquely  identified.  In  addition,  each 
task  must  be  assigned  a  code  which  the  model  uses  in  selecting  the 
particular  tasks  for  a  given  airplane,  component,  or  assembly.  Seven 
different  codes  have  been  established  for  this  purpose,  identified 
as  follows: 

Code  Definition 

D  Do  the  task 

S  Time  constrained  task 

B  Constrained  by  prior  task  completions 

A  Nonmutually  exclusive  selection 

E  Mutually  exclusive  selection 

F  Selection  governed  by  failure  mechanism 

C  Call  subnetwork 

Each  task  is  assigned  only  one  code.  Some  codes  require  additional 
information.  This  information  and  the  meanings  of  the  codes  are  fur¬ 
ther  described  below,  with  portions  of  the  network  shown  in  Fig.  2 
being  extracted  as  examples. 
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Coda  D — Do  the  Task 

Code  D  signifies  thac  Che  Cask  will  always  be  selecced  each  cime 
It  la  encouaCered,  and  ChaC  les  selection  Is  noc  subject  Co  chance  or 
any  ocher  criteria.  The  code  Is  usually  assigned  to  sequendal  Casks 
as  lllustraCed  In  Fig.  3.  Processing  will  continue  past  a  Code  D 
task  and  Into  subsequent  portions  of  Che  network. 


PRE- 
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Fig.  3  --  Example  of  Code  D,  B,  and  S  assignments 


Coda  S — Time  Cone  trained  Task 

This  code  Is  assigned  Co  the  sortie  task,  or  any  task  whose  start¬ 
ing  Cine  Is  to  be  controlled  by  the  mission  data.  When  this  code  is 
encountered  on  a  task,  mission  data  are  referenced  in  order  to  estab¬ 
lish  the  earliest  possible  starting  time.  If  the  preceding  task  is 
completed  and  other  mission  requirements  are  satisfied  (to  be  covered 
in  Sec.  Ill),  the  task  will  be  started.  The  assignment  of  this  code 
Is  illustrated  In  Fig.  3. 

Coda  B — Constrained  by  Prior  Task  Completions 

A  task  is  considered  normally  constrained  if  it  cannoC  be  started 
until  a  number  of  preceding  tasks  in  parsllel  have  all  been  completed. 
In  the  model,  the  assignment  of  Code  B  to  a  constrained  task  insures 
that  all  tasks  leading  directly  to  it  are  completed  before  attempting 
to  start  it.  Failure  to  assign  this  code  would  allow  the  constrained 
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cask  Co  be  scarced  as  ofcen  as  Chere  are  Casks  leading  Co  it,  result- 
lng  In  auldple  processing  of  all  following  casks.  Figure  3  also 
illuscraces  Che  use  of  chls  code. 

Code  A — Nonmutually  Exclusive  Selection 

This  code  Is  assigned  co  each  cask  In  a  sec  of  parallel  casks 
ChaC  may  be  selecced  independently.  In  the  operation  of  Che  model, 
each  parallel  cask  is  separately  and  independently  checked  Co  deter¬ 
mine  whether  or  not  It  will  be  selected.  Selection  is  based  upon  a 
probability  factor  that  must  be  assigned  whenever  Code  A  is  used. 

This  factor  represents  the  fraction  of  times  the  task  will  be  selected 
on  an  average.  For  example,  if  the  assigned  factor  is  0.10,  the  task 
will  be  selected  once  out  of  every  ten  times  it  is  encountered  on  an 
average.  The  model  selects  a  task  by  generating  a  random  number  be¬ 
tween  zero  and  one,  and  comparing  it  against  the  probability  factor. 

If  the  random  number  is  less  than  or  equal  to  the  factor,  the  task  is 
selected  for  processing;  otherwise,  it  is  not  selected.  In  this  way, 
the  actual  task  selection  is  subject  to  chance. 

As  illustrated  in  Fig.  4,  each  of  the  parallel  tasks  may  be  as¬ 
signed  a  different  probability  factor.  Since  selections  are  subject 
to  chance,  none,  one,  more  than  one,  or  all  tasks  in  the  set  may  be 
selected  when  encountered.  Over  the  long  run,  however,  as  a  number 
of  aircraft  or  components  are  exposed  to  this  portion  of  the  network, 
the  selection  frequency  will  approximate  the  assigned  probability 
factors . 


Fig.  4  —  Example  of  Code  A  assignment 
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Code  A  la  often  uaed  to  determine  which  parts  cause  the  failure 
of  a  component  or  assembly.  This  code  represents  real-world  uncer¬ 
tainties,  since  it  is  never  known  in  advance  which  parts  will  cause 
a  given  assembly  to  fail.  Only  expectations,  as  represented  by  the 
probability  factors  described  above,  can  be  determined  from  a  large 
number  of  previous  assembly  failures. 

Code  E — Mutually  Exclusive  Selection 

Code  E  is  assigned  to  each  member  of  a  set  of  parallel  tasks 
wherein  one  and  only  one  task  is  to  be  selected  according  to  respec¬ 
tive  probability  factors.  The  selection  procedure  is  similar  to  that 
for  Code  A.  Each  task  is  assigned  a  probability  factor,  and  a  random 
number  is  again  compared  against  the  probability  factors  in  the  selec¬ 
tion  procedure.  In  this  case,  however,  only  one  random  number  is 
used  for  the  whole  set  of  tasks  and  is  compared  against  the  sum  of 
probability  factors  as  successive  members  of  the  set  are  considered. 

The  particular  task  for  which  the  random  number  is  first,  less  than, 
or  equal  to  the  cumulative  value  of  the  probability  factors  is  selected 
for  processing,  and  the  procedure  terminates  since  only  one  task  is 
selected.  The  probability  factors  assigned  to  tasks  in  the  set  must 
add  up  to  one  to  Insure  that  a  member  of  the  set  is  selected. 

The  Code  E  assignment  is  illustrated  in  Fig.  5.  Notice  that  the 
probability  factors  add  up  to  one.  This  code  is  often  used  to  deter¬ 
mine  whether  a  particular  assembly  should  be  repaired  at  base  or 
depot  level.  The  probability  factor  for  depot  repair  is  referred  to 
as  the  NETS  (Not  Reparable  This  Station)  percentage.  Code  E  enables 
simulation  of  this  real-world  process:  whether  a  given  assembly  is 
repaired  at  base  or  at  depot  is  subject  to  chance,  but  the  choices 
for  a  large  number  of  the  assembly  will  be  distributed  as  indicated 
by  the  NETS  percentage. 
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Fig.  5  --  Example  of  Code  E  assignment 


Code  F — Selection  Governed  by  Failure  Mechaniim 

As  aircraft  undergo  flying  operations,  malfunctions  of  particular 
components  may  occur  that  must  be  corrected  before  the  airplane  la 
again  available  for  use.  These  kinds  of  failures,  as  well  as  others, 
can  be  represented  in  the  simulation  model  by  a  failure  mechanism 
described  later.  As  part  of  this  logic,  however,  Code  F  must  be 
assigned  to  certain  tasks. 

In  principle.  Code  F  is  used  to  select  those  tasks  leading  to 
and  involving  the  repair  of  an  airplane  or  component  that  has  had  a 
lower  level  part  failure.  For  a  given  exposure  to  the  network,  the 
failure  mechanism  determines  if  the  tasks  are  to  be  selected.  Code  F 
determines  which  tasks  are  involved  and  subject  to  selection. 

The  assignment  and  use  of  Code  F  may  best  be  described  by  refer¬ 
ring  to  the  example  network  in  Fig.  2  and  the  extracted  portion  shown 
in  Fig.  6.  Suppose  that  when  a  particular  airplane  undergoes  the 
simulated  flight  task,  the  hydraulic  pump  (Assembly  HI)  falls  and  must 
be  replaced  after  the  flight.  In  order  to  get  to  the  tasks  involving 
the  removal,  replacement,  and  repair  of  the  pump,  the  task  represent¬ 
ing  the  dispatch  of  hydraulic  system  technicians  must  be  selected. 

This  task  is  assigned  Code  F.  It  tells  the  model  that  when  the  pump 
fails,  the  dispatch  and  subsequent  tasks  must  be  accomplished;  and  if 
the  pump  does  not  fail,  these  tasks  are  not  selected.  In  this  way, 
Code  F  controls  the  entry  into  lower  levels  of  the  task  network  in 
accordance  with  malfunction  determinations. 
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Fig.  6  —  Example  of  Code  F  assignment 


Cods  C — Call  Svbnstuork 

Whan  a  caak  with  Coda  C  ia  encountered,  it  la  to  be  replaced  by 
a  aaparataly  constructed  subnetwork  of  tasks.  A  Code  C  task  is 
actually  a  "dummy"  in  the  sense  that  it  does  not  require  time  or  re¬ 
sources  but  merely  identifies  the  subnetwork  to  insert  at  this  point. 
The  first  task  in  the  subnetwork  is  processed,  then  the  second,  and 
so  on.  When  all  subnetwork  tasks  are  completed,  the  processing  re- 
warts  back  to  the  main  network  and  the  task  or  tasks  immediately 
following  the  Code  C  task  are  next  considered.  Code  C  is  illustrated 
in  fig.  7. 

A  subnetwork  of  tasks  may  be  constructed  just  like  the  main  net¬ 
work  itself.  All  of  the  task  type  codes  may  be  used,  including  Code 
C.  Thus,  a  main  network  may  call  a  subnetwork  which,  in  turn,  may 
call  a  sub-subnetwork,  and  so  forth.  This  feature  enables  an  overall 
task  network  to  be  constructed  in  separate  sections  and  allows  a 
particular  section  to  appear  in  several  places  without  duplication. 

In  more  sophisticated  uses,  a  subnetwork  can  even  call  itself  as,  for 
assails,  in  simulating  repeated  attempts  to  repair  an  article  where 
the  success  of  each  attempt  is  subject  to  chance. 
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NETWORK  PROCESSING 

The  task  network  described  above  controls  which  processes  will 
be  selected  and  represented  in  the  simulation.  Normally,  entry  into 
the  network  is  caused  by  a  mission  requirement.  For  each  airplane 
the  mission  requires,  a  record  is  established  that  represents  the 
aircraft  through  subsequent  operations.  According  to  type  of  sortie 
involved  in  the  mission,  an  initial  or  starting  task  in  the  network 
is  selected,  and  the  next  task  is  identified  in  a  data  element  of  the 
airplane  record.  When  the  first  task  is  completed,  the  data  element 
determines  where  to  go  next  in  the  task  network.  When  a  new  task  is 
selected,  its  successor  task  is  identified  in  the  airplane  record. 

In  this  way,  the  airplane's  location  in  the  task  network  at  any  time 
is  known.  The  codes  assigned  to  the  various  tasks  determine  whether 
or  not  they  will  be  incurred  as  the  airplane  progresses  through  the 
network  during  the  simulation. 
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When  the  network  indicates  the  removal  of  a  component  from  the 
airplane,  the  model  establishes  a  new  record  to  represent  the  compo¬ 
nent.  This  record  is  processed  through  its  portion  of  the  network 
in  a  fashion  similar  to  that  for  the  airplane.  If  an  assembly  is 
removed  from  the  component,  the  model  creates  and  processes  a  record 
for  the  assembly.  This  procedure  continues  to  the  extent  prescribed 
by  the  task  network. 

As  tasks  are  processed,  resource  requirements  are  determined. 

The  availability  and  interaction  of  the  resources  determine  whether 
the  task  will  start  right  away  or  be  delayed.  The  logic  involved  in 
this  decision  is  described  later.  Whenever  a  task  is  completed,  con¬ 
trol  reverts  back  to  the  network  to  determine  what  should  be  considered 
next.  This  procedure  continues  until  the  airplane,  component,  or 
assembly  returns  to  a  serviceable  or  ready-for-use  status. 

INPUT  DATA  FOR  TASK  NETWORKS 

After  the  task  network  is  constructed  and  annotated  with  task  and 
node  labels,  codes,  and  selection  probabilities,  the  data  are  trans¬ 
cribed  onto  an  input  form.  Such  a  form,  partially  completed  with  data 
from  the  example  network  in  Fig.  2,  is  shown  in  Fig.  8.  Each  task  is 
represented  by  a  line  of  data.  The  first  field  contains  a  preprinted 
card  number  to  indicate  the  kind  of  data  being  input  to  the  computer. 

The  "Prior  Node”  field  contains  the  label  for  the  beginning  node  of 
the  task.  The  "Selection  Mode"  field  contains  the  task  type  code  as 
previously  described;  if  no  entry  is  made  in  this  field,  the  computer 
will  automatically  Insert  a  Code  D — DO  THE  TASK.  The  "Task  I.D." 
field  contains  the  label  for  the  task  itself.  The  "Next  Node"  field 
contains  the  label  for  the  ending  node  of  the  task.  The  "Selection 
Parameter"  field  contains  the  selection  probability  factors;  this 
field  must  be  completed  whenever  a  task  type  Code  A  or  E  is  assigned. 
Finally,  the  "Task  Description"  field  may  be  used  to  enter  any  desired 
Information  further  describing  the  task  for  reference  purposes;  the 
model  does  not  use  this  information  in  any  of  its  processing. 

As  can  be  seen,  preparing  the  input  data  for  task  networks  is 
quite  simple  and  straightforward  once  the  networks  have  been  constructed. 
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Hovever,  the  initial  drawing  of  the  networks  to  capture  the  environ¬ 
ment  adequately  can  be  challenging,  since  it  requires  not  only  tech¬ 
nical  familiarity  with  the  processes  being  simulated,  but  also  judg¬ 
ment  with  respect  to  the  level  of  detail  appropriate  to  particular 
study  objectives.  Since  the  task  netvcrks  constitute  the  foundation 
of  the  L-COM  model,  careful  attention  is  required  for  their  construc¬ 
tion.  But  if  properly  developed  and  applied,  the  task  network  concept 
places  in  the  user's  hands  the  ability  to  describe  the  environment  as 
he  pleases,  without  being  forced  to  accept  a  particular  description 
that  wculd  otherwise  be  frozen  into  the  model  logic.  With  experience 
in  its  use,  this  distinguishing  feature  can  be  extremely  valuable  in 
applying  simulation  to  many  problem  areas  and  planning  studies  rela¬ 
ting  to  base  operations. 
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III.  PREPROCESSOR 


Any  simulation  model  of  reasonable  size  and  scope  requires  a 
considerable  amount  of  input  data.  As  more  features  of  the  real- 
world  environment  are  included,  more  data  are  required  to  describe 
them.  To  help  make  this  data  preparation  problem  as  easy  as  possible 
for  the  user,  it  is  desirable  that  he  have  input  forms  explicitly 
designed  for  his  convenience,  rather  than  for  the  simulation  model 
itself.  This,  however,  requires  a  computer  program  to  translate  the 
data  into  the  particular  formats  the  simulation  program  uses.  The 
Logistics  Composite  Model  has  a  preprocessor,  or  input  program, 
developed  for  this  general  purpose.  The  program  is  described  in  this 
section. 

FUNCTIONS  OF  THE  PREPROCESSOR 

In  the  L-COM  model,  the  preprocessing  routine  accomplishes  the 
following  three  functions: 

Edits  and  error-checks  input  data. 

Reformats  and  reorganizes  input  data  for  entry  into  the 

s imulation . 

Develops  sortie  requirements  according  to  a  specified 

flying  program. 

In  the  edit  and  error-checking  function,  the  preprocessor  analyzes 
data  elements  to  insure  their  completeness  and  accuracy  insofar  as 
possible.  For  example,  codes  such  as  the  task  type  described  in 
Sec.  II  are  inspected  for  illegal  entries.  Also,  certain  consistency 
checks  are  made;  for  example,  the  data  describing  task  networks  are 
analyzed  to  insure  that  all  the  tasks  are  properly  connected.  When¬ 
ever  errors  or  inconsistencies  are  detected,  messages  are  printed  out 
for  user  attention  and  correction. 

As  part  of  the  edit  process,  data  field  descriptions  designed 
for  user  convenience  are  translated  into  those  required  by  the  simu¬ 
lation  model.  For  example,  a  user  may  insert  the  number  five  in  a 
data  field  as  either  "5"  or  "5."  or  "5.0",  and  the  number  may  be 
placed  anywhere  within  the  designated  field  of  the  input  form.  The 
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preprocessor  will  then  convert  the  number,  however  entered,  into  a 
standard  format.  Similar  features  are  provided  for  alphanumeric  data 
and  for  time  values  that  may  be  input  by  the  user  in  days,  hours, 
minutes,  or  combinations  thereof,  according  to  his  convenience. 

After  the  data  are  edited,  they  are  reorganized  into  formats 
required  for  input  to  the  main  simulation  model.  These  formats  are 
prescribed  by  the  S1MSCRIPT  language  in  which  the  model  is  written. 

The  reformatted  data  are  identified  as  "initialization”  data  for  the 
simulation  model. 

On  one  of  the  input  forms,  the  user  may  specify  a  flying  program 
to  include  in  the  simulation.  The  form  provides  several  options  for 
specifying  the  flying  program,  so  the  preprocessor  can  generate 
specific  mission  requirements  in  terms  of  various  types  of  sorties 
to  be  accomplished  during  simulation.  The  corresponding  data  are 
produced  in  formats  prescribed  by  the  SIMSCRIPT  language.  These  are 
referred  to  as  "exogenous  event"  data,  since  they  represent  real-world 
events  coming  from  outside  of  the  support  environment  being  simulated. 

The  preprocessor  also  produces  reports  containing  the  results 
of  these  functions.  In  particular,  it  provides  listings  of  the  input 
data  for  reference  purposes. 


INPUT  FORMS 

To  provide  data  required  by  the  main  simulation  model,  the  pre¬ 
processor  uses  the  following  input  forms: 


Form  Number 


Description 


10 

Performance  Summary  Repo 
Specifications 

11 

Task  Network 

12 

Task  Definitions 

13 

Resource  Definitions 

14 

Failure  Clock  Decrements 

15 

Distributions 

16 

Shift  Change  Policies 

17 

Mission  Entry  Points 

18 

Priority  Specifications 

20 

Sortie  Generation  Data 

These  forms,  illustrated  in  Fig.  9,  are  briefly  described  below  with 


FORM  20 
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Input  forms  used  by  L-COM  Model 


respect  to  the  kinds  of  data  they  contain;  specific  data  elements 
contained  in  these  forms  are  listed  in  Appendix  A. 

i 

Fom  10 — Performance  Summary 
Report  Sped fi cations 

On  Form  10,  the  user  specifies  the  frequency  with  which  the  per- 
fermance  summary  report  is  to  appear.  A  basic  reporting  cycle  of  a 
day,  week,  or  other  period  may  be  prescribed,  with  an  overall  summary 

I 

being  produced  weekly,  monthly,  or  some  other  multiple  of  the  basic 
cycle.  In  addition,  entries  on  this  form  enable  the  user  to  specify 
what  should  be  printed  as  columnar  headings  on  the  performance  sum¬ 
mary  report.  In  general,  the  input  data  give  the  user  control  over 
the  meanings  of  the  columnar  breakouts  of  this  output  report. 

Form  ll — Task  Network 

Form  11  contains  data  for  the  task  networks.  It  is  described  in 
Sec.  II. 

Form  12 — Task  Definitions 

Form  12  provides  additional  data  for  each  different  kind  of  task. 
Included  are  task  priority,  task  duration  parameters,  and  task  re¬ 
source  requirements  in  terms  of  kinds  and  amounts  of  resources  needed 
to  accomplish  the  task. 

Form  13 — Resource  Definitions 

Tot  each  resource  required  by  one  or  more  task(s) ,  additional 
data  are  provided  on  Form  13.  Included  are  identifications  of  substi¬ 
tutes,  if  any,  unit  costs,  authorized  quantities,  failure  parameters, 
and  a  resource  type  code  identifying  resources  as  aircraft,  parts, 
men,  AGE,  or  facilities. 

Form  14--Failure  Clock  Decrements 


When  certain  tasks  occur,  a  number  of  particular  resources  may 
be  exposed  to  possible  failure.  Form  14  identifies  these  tasks  and 
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associated  resources,  and  gives  the  kind  and/or  amount  of  exposure 
to  failure.  These  data  are  used  in  the  model's  failure  mechanism. 

Form  l5--Distributior.s 

Several  factors  in  the  simulation,  such  as  task  durations  and 
times  between  part  failures,  are  subject  to  uncertainty,  which  is 
represented  in  the  model  by  drawing  random  values  from  probability 
distributions.  If  the  user  wishes  to  use  actual  data,  as  obtained 
from  real-world  observations.  Form  15  is  used  to  enter  probability 
distributions  in  terms  of  histograms.  Otherwise,  he  may  specify  any 
one  of  several  standard  distributions  such  as  the  normal  or  exponen¬ 
tial  functions  that  the  model  contains. 


Form  l6--Shift  Change  Foliates 


Any  resource  included  in  the  simulation  may  be  subject  to  a 
shift  change  policy  whereby  its  authorized  level  is  changed  over  time. 
Form  16  contains  data  specifying  the  resources  subject  to  shift 
changes,  the  time  durations  of  the  various  shifts,  and  the  authorized 
levels  for  each  shift. 


Fom  17 — A fission  Entr y  Points 


When  a  mission  requirement  occurs,  available  aircraft  are  selected 
for  processing  through  the  task  network.  Since  the  tasks  involved 
may  differ  by  type  of  mission,  different  initial  entry  points  into 
the  overall  task  network  may  be  necessary.  Form  17  identifies  these 
initial  points  of  entry. 


Form  13 — Priority  Specifications 


This  form  contains  priority  level  definitions  and  other  factors 
representing  maintenance  policies  for  expedited  repair,  preemption  of 
in-process  tasks,  the  use  of  overtime,  and  other  policies  as  described 
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Fom  20 — Sortie  Generation  Data 

Form  20  contains  data  prescribing  the  flying  program.  These 
data  and  the  way  the  preprocessor  uses  them  to  generate  sorties  are 
further  described  below. 

SORTIE  GENERATOR 

The  following  data  characterize  each  mission  requirement: 

Type  of  mission. 

Type  of  aircraft  required. 

Desired  takeoff  time. 

Preparation  time  prior  to  takeoff  (lead  time). 

Mission  length. 

Mission  cancellation  time. 

Possible  types  of  missions  are:  close  support,  interdiction, 
reconnaissance ,  training,  and  so  forth;  different  types  of  missions 
may  involve  different  kinds  of  support  tasks,  such  as  weapons  loading 
and  other  preflight  operations.  It  is  assumed  that  all  airplanes  in 
a  given  mission  are  the  same  type.  If  different  types  are  required, 
separate  missions  are  specified. 

The  number  of  airplanes  required  for  each  mission  is  specified 
in  terms  of  a  minimum,  a  maximum,  and  spares.  During  the  simulation; 
the  maximum  number  will  be  flown  if  possible.  If  less  than  the  mini¬ 
mum  are  available,  the  entire  mission  will  be  canceled.  Spare  air¬ 
planes,  if  any,  are  prepared  for  flight  and  held  in  reserve  in  case 
other  mission  airplanes  cannot  be  made  ready  in  time  or  would  other¬ 
wise  abort  the  mission. 

The  desired  takeoff  time  occurs  when  all  aircraft  in  the  mission 
are  ready  to  depart.  If  some  or  all  of  the  airplanes  are  not  ready, 
takeoff  time  is  deferred,  but  no  later  than  the  mission  cancellation 
time.  If  enough  airplanes  are  not  ready  by  this  time,  the  mission 
is  canceled. 

The  mission  lead  time  represents  the  time  prior  to  takeoff  allowed 
for  accomplishing  presortie  tasks,  such  as  preflight  maintenance  or 
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weapons  loading.  If,  during  Che  simulation,  the  actual  presortie 
tasks  extend  beyond  the  scheduled  takeoff  time,  the  mission  will  be 
delayed  or  possibly  canceled.  If  the  airplanes  take  off,  the  mission 
length  is  the  actual  time  spent  on  the  sortie;  it  Is  the  same  for  all 
airplanes  in  the  mission. 

One  of  the  preprocessor's  functions  is  to  generate  a  list  of 
missions  with  specific  values  for  the  above  data  elements.  The  user 
provides  input  data  for  this  purpose  on  Form  20 — Sortie  Generation 
Data.  On  this  form,  several  options  are  available  with  respect  to 
the  level  of  detail  in  which  the  mission  data  are  provided.  As  one 
option,  specific  values  may  be  assigned  to  the  data  elements  for  each 
mission.  This  is  particularly  useful  for  representing  real  world 
missions  in  the  simulation.  In  the  other  options,  specific  values 
for  one  or  more  of  the  data  elements  are  randomly  selected  from  prob¬ 
ability  distributions  or  histograms,  rather  than  being  explicitly 
given  by  the  user. 

As  an  example,  the  number  of  missions  of  a  given  type  to  be 
accomplished  during  a  specified  day  may  be  obtained  (by  the  prepro¬ 
cessor)  from  a  probability  distribution.  Similarly,  takeoff  times 
may  be  randomly  determined  from  histograms  representing  mission  fre¬ 
quencies  as  a  function  of  time  of  day.  The  mission  length  may  also 
be  randomly  determined  from  a  probability  distribution;  if  a  standard 
distribution  is  used,  the  user  normally  supplies  a  mean  and  standard 
deviation.  Finally,  missions  may  be  rescheduled  at  a  daily  interval 
over  a  specified  time  span.  This  feature  enables  the  user  to  repre¬ 
sent  repetitions  of  the  daily  flying  program  over  longer  time  inter¬ 
vals  without  repeating  the  input  data. 

The  form  for  entering  flying  program  data  allows  for  any  mix  of 
the  above  options.  Thus,  some  missions  may  be  explicitly  prescribed 
while  others  may  be  specified  by  the  random  processes  described  above. 
Certain  mission  types,  such  as  training  sorties,  may  be  caused  to 
occur  repetitively  throughout  the  simulation  according  to  a  prescribed 
pattern.  According  to  the  kind  of  data  provided  on  the  fora,  the 
preprocessor  accomplishes  the  functions  necessary  to  generate  a  list 
of  specific  missions  for  input  to  the  simulation. 
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OUTPUT  REPORTS 

As  part  of  its  operation,  the  preprocessor  produces  the  follow¬ 
ing  kinds  of  reports: 

Error  Messages 
Task  Network  Analyses 
Mission  Summary 
Dictionary  of  Assigned  Names 
Initialization  Data 

For  the  error  messages,  relevant  information  is  either  separately 
printed  or  interspersed  in  the  other  reports  according  to  type  of 
error  involved.  These  messages  contain  explicit  information  pertain¬ 
ing  to  and  describing  the  error  involved.  The  outputs  of  the  task 
network  analyses  provide  another  class  of  potential  errors.  In 
addition  to  a  printout  of  the  task  network  data,  results  of  various 
consistency  checks  are  produced.  Included  are  identifications  of 
network  entry  points,  undefined  nodes,  and  nodes  that  are  multiply- 
referenced  in  the  network  data.  This  information  may  be  used  to 
locate  errors  in  the  construction  of  the  task  networks. 

The  mission  summary  report  contains  results  of  the  mission  genera¬ 
tion  procedure.  It  lists  all  data  pertaining  to  the  missions  generated 
by  day,  mission  type,  and  aircraft  type. 

Printouts  for  initialization  data  are  presented  in  two  formats. 

One  corresponds  closely  to  the  input  forms  the  user  fills  out.  The 
other  represents  the  translation  of  this  data  for  input  to  the  simu¬ 
lation  program;  this  format  is  prescribed  by  the  SIMSCRIPT  initializa¬ 
tion  procedure. 

Aside  from  the  error  messages,  the  preprocessor  outputs  are  used 
mostly  for  reference  purposes.  They  contain,  in  a  consolidated 
printout,  all  of  the  input  data  used  by  the  mode.  The  outputs  also 
include  a  summary  of  the  total  number  of  tasks,  network  nodes,  re¬ 
sources,  and  failure  clocks  that  are  contained  in  the  simulation. 

The  dictionary  produced  by  the  preprocessor  references  resource 
numbers  and  task  numbers  used  by  the  simulation  program  to  the  respec¬ 
tive  names  assigned  in  the  input  data.  These  references  are  required 
to  relate  certain  outputs  of  the  simulation  model  to  the  input  data; 
they  are  also  needed  to  produce  postprocessor  outputs. 
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IV.  SIMULATION  PROGRAM 


The  simulation  program  constitutes  the  main  part  of  the  Logistics 
Composite  Model.  This  program  represents  and  simulates  interactions 
of  base  operations  and  support  processes  in  accomplishing  mission 
requirements.  This  section  describes  the  structure  and  logical  pro¬ 
cedures  of  this  program. 

GENERAL  DESCRIPTION 

The  main  simulation  model,  using  the  task  network  concept  des¬ 
cribed  in  Sec.  II  and  responding  to  mission  requirements  generated  as 
described  in  Sec.  Ill,  is  designed  to  simulate  a  broad  range  of  air¬ 
craft  operations,  scheduling,  maintenance,  and  supply  functions  at 
an  Air  Force  base.  For  each  mission  requirement,  th?  program  inter¬ 
nally  controls  the  processing  of  each  aircraft  towara  the  completion 
of  the  mission  as  illustrated  schematically  in  Fig.  10. 

As  in  real  life,  the  model  attempts  to  complete  all  missions, 
but  some  cannot  be  completed  as  scheduled.  Actions  which  could  cancel 
a  mission  are  the  unavailability  of  sufficient  aircraft  to  schedule 
into  presortie  processes  or  the  loss  of  aircraft  to  unscheduled  main¬ 
tenance  according  to  failures  detected  in  presortie  tasks. 

After  the  mission  is  completed,  the  airplanes  undergo  postsortie 
maintenance  as  prescribed  by  the  task  network.  Normally  included  are 
debriefing  and  troubleshooting  tasks  wherein  aircraft  system  failures 
are  detected  and  their  correction  begun.  This  phase  of  the  simulation 
generates  demands  for  spare  parts  from  supply,  and  simultaneously 
generates  reparable  assemblies  for  maintenance  in  one  or  more  of  the 
base  repair  shops  or,  in  the  case  of  NRTS  items,  depot-level  repair 
facilities . 

At  this  point,  the  maintenance  simulation  follows  two  distinct 
paths,  one  for  the  aircraft  itself  (flight-line  maintenance)  and  one 
for  the  reparable  assembly  (shop  maintenance).  Flight-line  maintenance 
consists  of  those  tasks  required  to  troubleshoot  and  remedy  failures 
on  the  aircraft  or  to  replace  faulty  items  with  serviceable  spares. 


SIMULATION  CONTROL 


Schematic  of  main  simulation  model 
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After  all  aircraft  maintenance  is  completed,  the  airplane  is  returned 
to  a  serviceable  pool. 

Shop  maintenance  tasks  are  those  base  or  depot  processes  required 
to  diagnose  faults  in  the  reparable  assembly  and  remedy  failures  by 
repair  and/or  replacement  of  one  or  more  of  its  subassemblies  from 
serviceable  stock.  In  this  process,  a  second  indenture  reparable  may 
be  generated  for  further  base  or  depot  repair.  As  prescribed  by  the 
task  network,  this  procedure  can  be  repeated  for  successively  lower 
levels  of  indenturing,  with  each  reparable  being  followed  through  its 
set  of  maintenance  tasks  . 

Whether  to  repair  an  item  at  base  or  depot  is  a  random  choice 
based  upon  the  input  NRTS  percentage  for  the  item.  In  each  case,  the 
reparable  follows  a  specific  set  of  tasks;  for  the  depot,  the  pro¬ 
cesses  may  be  abstracted  into  a  single  task  representing  the  overall 
depot  order  and  shipping  time.  Upon  completion  of  designated  tasks, 
the  unit  is  returned  to  supply  as  a  serviceable  item  and  appropriate 
stock  levels  are  incremented. 

In  simulating  repair  and  other  kinds  of  tasks,  conflicts  may 
arise  over  resource  availability.  There  may  be  insufficient  amounts 
of  a  given  resource  item  to  satisfy  all  requirements  at  a  particular 
time.  To  resolve  these  conflicts,  a  priority  system  is  used  as  well 
as  logical  processes  for  using  substitute  items,  expediting  parts  out 
of  repair  shops,  preempting  lower  priority  tasks,  and  cannibalizing 
parts  off  of  airplanes  down  for  other  reasons. 

To  simulate  parts'  failure  which,  in  turn,  controls  the  occur¬ 
rence  of  repair  tasks,  the  program  logic  provides  a  failure  mechanism 
that  uses  failure  probability  distributions  based  upon  parts  reliability 
data  to  determine  when  failures  occur.  It  also  exercises  appropriate 
portions  of  the  task  network. 

A  shift  mechanism  within  the  simulation  program  permits  identi¬ 
fied  resources,  such  as  personnel,  to  be  utilized  on  a  shift  basis. 

Such  resources  are  designated  as  working  under  specific  shift  policies; 
several  policies  may  operate  at  the  same  time.  At  appropriate  shift 
intervals  during  the  simulation,  levels  of  associated  resources  are 
incremented  or  decremented  as  required. 
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Data  are  collected  during  the  entire  operation  of  the  simulation 
program  and  at  specified  times  are  produced  in  output  formats.  The 
main  output  is  a  performance  summary  report  containing  summary  statis¬ 
tics  for  all  major  functional  areas  of  the  base  operation.  The  user 
may  also  produce  several  status  reports  if  he  wants. 

INPUT  DATA 

As  illustrated  in  Fig.  1,  the  main  simulation  program  receives 
four  types  of  input  data  as  follows: 

Mission  requirements  data 
Initialization  data 
Run  specification  data 
Decision  model  input  data 

The  mission  requirements  data,  generated  by  the  preprocessor  for 
input  to  the  simulation,  specify  the  kinds  of  missions  to  be  simulated, 
when  they  are  to  occur,  what  types  and  how  many  aircraft  will  be  needed, 
and  other  factors  as  described  in  Sec.  III. 

The  initialization  data,  prepared  by  the  preprocessor  for  use  by 
the  simulation  program,  contain  information  in  the  following  functional 
groupings  or  tables: 

Control  Table 
Task  Table 
Resource  Table 
Shift  Tables 
Failure  Data 

Network  Initial  Entry  Table 
Report  Data 

Priority  and  Other  Factors 

Within  each  of  these  groupings,  a  number  of  data  elements  are  provided 
by  input  fonas  as  summarized  in  Sec.  III. 

In  addition  to  data  obtained  from  the  preprocessor,  a  special 
form  is  used  to  specify  particular  features  of  tne  model  that  are  to 
be  exercised  when  the  simulation  program  is  run.  As  illustrated  in 
Fig.  11,  this  form  (Form  1 — Run  Specifications)  permits  the  entry  of 
a  run  identification  number  which  is  printed  on  all  output  reports, 
specifications  about  whether  the  forecast  or  decision  procedures  are 


-38- 


to  be  exercised,  and  identifications  of  special  reports  to  be  produced 
during  the  run.  This  form  may  be  separately  completed  for  each  run. 

If  the  embedded  decision  model  is  to  be  exercised  during  the 
simulation  (as  specified  on  Form  1),  additional  data  must  be  provided 
as  inputs  to  the  simulation  program.  This  data  and  corresponding 
forms  will  be  described  in  the  next  section. 

MISSION  REQUIREMENTS 

From  a  logical  processing  point  of  view,  the  simulation  program 
starts  when  a  mission  requirement  arrives  at  a  particular  point  in 
simulation  time.  Aircraft  availability  data  in  the  Resource  Table 
are  checked  to  determine  whether  sufficient  airplanes  are  available 
tc  fly  the  mission.  According  to  availability,  the  number  of  airr.ianes 
scheduled  for  the  mission  will  lie  between  the  minimum  number  required 
and  the  maximum  number  plus  spares,  as  specified  in  the  mission  data. 

If  the  minimum  number  is  not  available,  the  mission  requirement  is 
set  aside  until  airplanes  are  available  from  previous  missions. 

Each  airplane  assigned  to  the  mission  is  started  through  pre¬ 
flight  tasks  according  to  the  task  network  as  represented  by  the 
Control  Table.  The  first  task  to  be  incurred  depends  upon  the  mission 
type  and  is  so  identified  in  the  Initial  Entry  Table.  The  task  is 
started  if  the  prescribed  resources  for  the  first  task  are  available 
or  are  made  available  by  the  task  processing  described  below.  When 
the  task  is  completed  at  a  later  point  in  time,  reference  is  made  to 
the  Control  Table  to  determine  what  task  or  tasks  are  next  involved 
in  the  preflight  operations.  Again,  the  selected  tasks  are  started 
if  possible,  and  the  procedure  continues  until  all  preflight  tasks 
for  the  airplane  are  accomplished.  At  this  time,  the  a-’rplane  is 
flagged  as  mission  ready. 

When  mission  time  arrives,  the  mission  is  started  if  enough  air¬ 
craft  are  ready.  If  not,  it  is  delayed  until  either  sufficient  air¬ 
planes  become  available  or  the  time  to  cancel  the  mission  arrives, 
whichever  is  first.  The  airplanes  being  prepared  for  a  mission  that 
subsequently  does  r.ot  take  place  are  returned  to  the  on-hand  pool 


after  the  tasks  they  are  in  at  cancellation  time  are  completed. 
Similarly,  if  the  mission  is  canceled,  all  airplanes  are  returned  to 
the  on-hand  pool  in  lieu  of  starting  the  sortie  task. 

FAILURE  MECHANISM 

When  the  flight  task  and  other  specially  identified  tasks  are 
encountered,  the  model  logic  that  causes  item  and  equipment  failures 
to  be  represented  is  called  into  operation.  The  tasks  so  identified 
are  those  that  tend  to  cause  failures  in  the  real  world  because  they 
involve  the  operation  or  stressing  of  airplanes  or  other  equipment. 

As  part  of  the  input  data,  resource  items  likely  to  fail  are 
identified  for  each  failure-causing  ta3k.  Each  such  resource  is 
viewed  as  owning  a  clock  which  Cells,  at  any  given  time,  how  long  it 
will  be  before  its  next  failure  occurs.  Each  time  the  associated 
task  occurs,  Che  clock  is  reduced  by  an  appropriate  amount,  resulting 
in  a  shorter  remaining  time-to-failure . 

The  meaning  of  the  clock  and  the  amount  by  which  it  is  decre¬ 
mented  each  time  may  be  different  from  one  type  of  resource  to  another. 
For  example,  failures  for  landing  gears  are  related  to  number  of  land¬ 
ings  and,  therefore,  its  clock  tells  how  many  more  landings  will  occur 
before  a  failure  results.  In  this  case,  the  clock  is  reduced  by  one 
(representing  one  landing)  each  time  a  flight  task  occurs.  As  another 
example,  the  airplane  navigation  system  may  operate  whenever  the  air¬ 
plane  flies,  and  its  failures,  therefore,  are  related  to  cumulative 
flying  hours.  In  this  case,  the  clock  for  the  navigation  system  is 
read  as  flying  hours  until  next  failure;  It  is  decremented  by  the 
sortie  length  each  time  a  flight  cask  is  incurred.  Similarly,  clocks 
for  other  kinds  of  resources  may  be  scaled  in  terms  of  equipment 
operating  time,  calendar  time,  or  other  measures,  and  appropriately 
reduced  when  tasks  that  probably  cause  the  failures  are  encountered. 

Two  actions  are  taken  for  each  resource  whose  clock  reaches  zero. 
First,  the  clock  is  reset  to  some  value  selected  from  a  failure  prob¬ 
ability  distribution  for  the  item.  This  value  is  normally  a  random 
draw  from  a  distribution  of  times  (flying  hours,  number  of  landings. 
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etc.)  between  failures  as  determined  from  previous  experience.  Re¬ 
setting  the  clock  represents  the  uncertainty  involved  with  respect 
to  when  the  next  failure  will  happen  during  the  simulation. 

The  second  action  taken  is  to  open  up  portions  of  the  task  net¬ 
work  representing  correction  of  the  malfunction.  As  part  of  the  failure 
data,  all  tasks  whose  sequence  must  be  followed  in  effecting  the  repair 
of  a  given  part  are  identified  by  a  Code  F  in  the  task  network.  The 
last  task  in  this  sequence  will  have,  as  an  additional  identifier, 
the  name  of  the  resource  whose  clock  determines  the  failure.  This 
identifier  is  entered  in  the  failure  parameter  column  of  the  Network 
Data  Form  (Form  11).  In  this  way,  the  necessary  corrective  actions, 
as  identified  in  the  task  network,  are  taken  whenever  an  item  failure 
occurs . 

In  summary,  the  failure  mechanism  of  the  model  simulates  real- 
world  failures  with  respect  to  what  causes  them,  the  frequency  and 
randomness  of  occurrence,  and  the  identification  of  tasks  involved 
in  their  correction. 

TASK  PRIORITIES 

In  the  processing  described  below,  conflicts  among  tasks  may 
arise  because  of  a  shortage  of  required  resources.  To  resolve  these 
conflicts,  a  priority  system  has  been  established  as  part  of  the  model 
logic. 

As  one  of  the  data  elements  in  the  Task  Table,  a  priority  may  be 
assigned  to  each  task  in  the  network.  Any  convenient  priority  scale 
may  be  adopted,  such  as  1  to  10,  1  to  30,  or  1  to  100.  The  tasks  with 
the  lowest  priority  numbers  are  considered  the  most  important;  for 
example,  if  two  tasks  are  competing  for  the  same  resource,  the  one 
with  the  lowest  priority  number  will  obtain  it. 

For  some  rules  used  in  task  processing,  the  priorities  may  be 
categorized  in  three  groups.  If,  for  example,  a  priority  scale  of 
1  to  30  is  adopted,  the  respective  groups  might  consist  of  priorities 
1-10,  11-20,  and  21-30.  An  even  distribution,  as  in  this  example, 
however,  is  not  necessary;  the  user  may  divide  the  priority  scale 
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lnto  three  contiguous  regions  in  any  way  he  pleases.  These  priority 
groupings  are  described  below. 

In  addition  to  being  assigned  to  tasks,  the  priority  scale  may 
be  applied  to  missions.  In  this  case,  the  priorities  are  used  to 
determine  which  missions  will  obtain  airplanes  if  there  are  not  enough 
for  all  missions  at  a  particular  time.  In  general,  mission  priorities 
are  used  in  the  same  way  as  task  priorities,  with  airplanes  being  the 
applicable  resource.  As  in  the  real  world,  the  simulation  program 
uses  the  priority  system  to  represent  the  relative  importance  of  tasks 
or  missions  when  competing  for  s  arce  resources. 


TASK  START  PROCEDURES 


Whenever  a  cask  is  selected  for  processing,  as  determined  by  the 
network  representation  in  the  Control  Table,  a  common  set  of  pro¬ 
cedures  are  applied  that  either  start  the  task  or  place  it  in  a  back- 
order  status  awaiting  the  availability  of  needed  resources.  The  first 
step  in  this  procedure  is  to  determine,  from  data  contained  in  the 
Task  Table,  what  resources  and  how  much  of  each  resource  are  involved 
in  accomplishing  the  task.  It  is  further  determined,  from  Task  Table 
data,  whether  each  resource  is  to  be  temporarily  used  by  the  task, 
consumed  during  the  accomplishment  of  the  task,  or  generated  by  the 
cask.  These  possibilities  are  further  described  as  follows: 

Temporary  Use.  The  indicated  resource  amounts  are  used 
during  the  entire  task,  and  are  then  returned  for  use  by 
other  tasks.  This  is  normally  applicable  to  such  resource 
types  as  men,  equipment,  and  facilities. 

Consumption.  The  resource  is  either  used  up  by  the  task 
or  it  becomes  an  integral  part  of  an  airplane  or  a  higher 
assembly;  in  both  cases,  the  resource  is  not  returned 
when  a  task  is  completed  and  is  not  available  for  any 
further  use.  This  normally  applies  to  consumable  re¬ 
sources  such  as  fuel  and  ammunition,  and  to  repair  parts 
that  are  installed  in  airplanes  or  components  during  the 
task. 

Generate.  The  resource  is  generated  or  created  as  a 
separate  entity  during  the  accomplishment  of  the  task. 

This  normally  pertains  to  components  or  assemblies  that 
are  removed  from  airplanes  or  higher  order  assemblies 
and  which  undergo  subsec  lent  repair  or  other  processes 


as  independent  units.  This  feature  can  also  be  used  to 
simulate  work  done  that  is  not  related  to  any  specific 
resource. 

In  addition  to  resources  involved  in  the  task,  as  identified  by 
Task  Table  data,  there  is  always  a  specific  resource  item  associated 
with  the  task.  This  item  is  the  airplane,  component,  or  assembly 
that  is  separately  tracked  through  the  task  network  and  for  which  a 
data  record  exists  to  represent  the  item  as  it  incurs  appropriate 
tasks.  Each  task  selected  for  processing  is  identified  by  primary 
item  and  associated  data  record. 

After  associated  resources  and  resource  requirements  have  been 
determined,  it  is  necessary  to  determine  whether  resources  to  be 
temporarily  used  or  consumed  are  available.  For  each  such  resource, 
the  on-hand  balance  in  the  Resource  Table  is  checked.  If  sufficient 
amounts  of  all  needed  resources  are  available,  the  on-hand  balances 
are  appropriately  reduced,  due-in  balances  (also  data  elements  in 
the  Resource  Table)  are  correspondingly  increased,  and  the  task  is 
started.  If  sufficient  amounts  are  not  available  for  one  or  more 
required  resources ,  the  task  is  processed  furthe-  .  This  processing 
consists  of  a  series  of  steps  directed  toward  obtaining  the  required 
resources  by  other  means  as  follows: 

Use  of  substitutes 
Expedited  repair 
Task  preemption 

Accomplishing  these  steps  constitutes  a  filtering  process  in  the  sense 
that  they  are  done  in  sequence  and  the  search  terminates  at  the  step 
in  which  the  needed  resources  are  first  found.  The  logic  involved 
in  each  step  is  further  described  as  follows: 


Uee  of  5. destitutes 

If  there  are  insufficient  amounts  of  certain  resource  items, 
other  items  in  the  simulation  may  be  substituted.  Such  substitutes 
are  identified  in  the  Resource  Table.  Only  one  substitute  may  be 
listed  for  a  given  item;  however,  two  items  may  list  each  other  as 
substitutes . 
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When  there  is  not  enough  of  the  prime  item  to  meet  a  task  require¬ 
ment,  as  much  of  the  substitute  item  as  is  available  or  needed  to 
complete  the  requirement  is  allocated  to  the  task.  If  prime  and  sub¬ 
stitute  items  meet  all  task  requirements,  balances  are  appropriately 
adjusted  and  the  task  is  started.  Otherwise,  the  next  step  in  the 
search  for  resources  is  taken. 

Expedited  Repair 

If  prime  or  substitute  items  cannot  satisfy  task  requirements, 
other  tasks  currently  using  the  needed  resources  are  inspected  to 
determine  when  they  will  be  completed,  thereby  releasing  the  needed 
resources.  If  an  in-process  task  will  finish  soon  enough,  the  in¬ 
coming  task  is  set  aside  until  the  in-process  task  is  completed.  If 
not,  an  assumption  for  expediting  completion  of  the  in-process  task 
is  tested.  This  representation  of  expedited  repair  is  accomplished 
by  multiplying  the  remaining  task  duration  by  a  specified  fraction, 
such  as  0.80.  If  the  new  completion  time  for  the  in-process  task 
meets  the  waiting  time  criteria  for  the  incoming  task,  corresponding 
actions  are  taken  to  expedite  the  former  and  set  aside  the  latter. 

For  a  given  incoming  task,  several  in-process  tasks  may  be  sub¬ 
ject  to  the  above  processing  in  providing  all  of  the  resource  defi¬ 
ciencies.  Even  though  the  task  is  set  aside  until  the  resources  are 
released,  the  resources  are  not  committed  to  or  reserved  for  this 
task.  It  can  well  happen  thac  the  incoming  task  will  remain  in  a 
backorder  status  because  the  released  resources  are  used  by  other, 
higher-priority  tasks  coming  along  later. 

Task  Preemption 

Task  preemption  may  interrupt  in-process  tasks  of  lower  priority 
to  provide  the  needed  resources  to  higher  priority  tasks.  The  number 
of  in-process  tasks  that  are  interrupted  or  preempted  depends  upon 
the  priority  category  for  the  incoming  task.  As  examples,  highest 
priority  tasks  can  be  allowed  to  preempt  as  many  in-process  tasks  as 
necessary  to  recover  the  needed  resources,  while  low  priority  tasks 
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may  not  be  permitted  to  preempt  at  all.  The  input  data  specify  the 
maximum  number  of  tasks  each  priority  group  can  preempt. 

Tasks  with  the  lowest  priorities  are  preempted  first.  Each 
preempted  task  is  placed  in  a  backorder  status,  and  its  remaining 
processing  t  '.me  is  increased  by  a  specified  factor  to  represent  the 
additional  time  involved  in  starting  the  task  when  resources  again 
become  available.  However,  tasks  are  preempted  only  if  there  are 
enough  meeting  the  selection  criteria  to  satisfy  all  resource  defi¬ 
ciencies  for  the  incoming  task.  If  so,  the  preempted  tasks  are  back¬ 
ordered  and  the  incoming  task  is  started;  otherwise,  the  incoming  task 
is  backordered. 

In  both  the  expedited  repair  and  preemption  procedures,  substi¬ 
tute  items  as  well  as  prime  items  are  considered.  Thus,  in-process 
tasks  may  be  expedited  or  preempted  for  combinations  of  prime  and 
substitute  items,  so  long  as  sufficient  amounts  of  both  are  obtained 
to  meet  the  requirements.  In  no  case,  however,  can  both  expediting 
and  preempting  be  used. 

TASK  COMPLETION  PROCEDURES 

When  a  task  is  completed,  temporary  resources  are  released  and 
may  be  reused  for  other  tasks.  At  this  time,  a  search  is  made  to 
determine  whether  other  tasks  are  in  a  backorder  status  for  the  re¬ 
sources  being  released.  If  there  are  some,  they  are  ranked  by 
priority  and  the  task  starting  procedure  is  applied,  commencing  first 
with  the  highest  priority  task  in  the  list.  Before  :aing  ranked  and 
selected  for  this  processing,  however,  a  priority  escalation  procedure 
is  applied  to  the  backordered  tasks. 

The  escalation  procedure  increases  the  priority  of  tasks  that 
have  been  in  a  backorder  status  for  quite  a  while  so  that  they  can 
compete  better  for  the  resources  being  released.  Otherwise,  low 
priority  tasks  could  remain  in  a  backorder  status  throughout  the 
simulation.  The  time  a  task  must  be  backordered  before  its  priority 
is  increased  is  specified  by  an  input  factor  according  to  priority 
category . 
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After  priorities  have  been  adjusted  by  the  escalation  procedure, 
the  task  starting  procedure  is  applied  to  the  backordered  tasks  just 
as  if  they  were  new  tasks  being  generated.  This  is  done  because  the 
situation  has  changed  with  respect  to  the  use  of  substitutes,  expedited 
repair,  and  preemption  since  the  tasks  were  first  backordered.  Thus, 
even  though  released  resources  may  be  applied  against  backordered 
tasks,  further  opportunities  for  starting  backordered  tasks  may  now 
be  available.  The  starting  procedure  uses  both  the  released  resources 
and  the  other  possibilities  in  satisfying  requirements  of  backordered 
tasks . 

If  the  task  being  completed  generates  a  resource,  the  model  es¬ 
tablishes  a  record  to  represent  the  resource.  Reference  is  made  to 
the  Control  Table  to  determine  what  task  or  tasks  the  resource  incurs 
next  as  it  commences  its  own  path  through  the  network  as  an  indepen¬ 
dent  entity.  For  example,  the  task  being  completed  may  represent  the 
removal  of  a  component  from  an  airplane;  this  component  then  under¬ 
goes  a  set  of  shop  repair  tasks  as  prescribed  by  the  network.  The 
maintenance  personnel,  AGE,  or  other  resources  temporarily  used  in 
the  removal  task  are,  of  course,  released  for  further  use  as  described 
above . 

After  the  above  processing  is  accomplished  for  a  task  being  com¬ 
pleted,  reference  is  made  to  the  Control  Table  to  determine  which, 
if  any,  tasks  should  be  processed  next.  The  starting  procedure,  as 
previously  described,  is  then  applied  to  these  new  tasks.  In  this 
procedure,  a  newly  generated  task  may  preempt  a  previously  backordered 
task  that  has  just  started.  This  happens  rarely,  however,  because 
either  the  resource  contents  of  the  several  tasks  involved  differ  or 
the  new  task  has  the  same  or  lower  priority  than  the  previously  back¬ 
ordered  task.  On  the  other  hand,  the  procedures  that  apply  at  the 
start  and  end  of  a  task  interrelate,  and  a  variety  of  complex  situa¬ 
tions  can  result. 

camibalizatiov 

When  a  mission  requirement  occurs  and  there  are  not  enough  air¬ 
planes  available,  a  cannibalization  procedure  may  be  applied  to 
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acquire  the  needed  airplane  or  airplanes.  In  this  procedure,  a 
search  is  made  for  airplanes  that  are  inoperative  because  they  lack 
parts.  If  an  airplane  is  missing  not  more  than  two  parts  and  is 
otherwise  serviceable,  the  cannibalization  procedure  obtains  the 
needed  parts  from  a  down  airplane  that  is  missing  the  most  parts 
other  than  those  needed.  This  procedure  consolidates  parts  shortages 
into  one  airplane.  However,  an  airplane  with  more  than  five  parts 
shortages  will  not  be  considered  as  a  candidate  for  cannibalization. 

Appropriate  tasks  are  then  generated  to  represent  the  removal 
of  the  parts  from  the  cannibalized  airplane  and  their  installation 
on  Che  airplane  being  prepared  for  the  mission.  If  these  tasks  are 
accomplished  in  time,  the  airplane  is  used  for  the  mission.  Other¬ 
wise,  the  mission  may  be  canceled  and  the  airplane  used  later.  Mean¬ 
while,  the  cannibalized  airplane  might  remain  in  an  unserviceable 
status  a  longer  time  because  it  now  lacks  more  parts. 

SHIFT  CHANGES 

The  shift  change  procedure  causes  increases  or  decreases  in 
resource  availabilities  at  specified  times  during  the  simulation. 

This  procedure  can  represent  changes  in  manning  levels  for  different 
shifts  during  the  day,  as  well  as  changes  in  other  resource  levels. 

The  Shift  Tables  contain  data  prescribing  what  resources  are  affected, 
when  their  levels  are  changed,  and  by  how  much.  These  tables  may 
represent  several  shift  policies,  and  give  a  list  of  resources  sub¬ 
ject  to  each  policy.  Each  policy  has  its  own  shift  pattern  that 
prescribes  when  shift  changes  occur.  A  shift  pattern  consists  of 
several  shift  intervals  and  instructions  concerning  their  repetition. 
Each  interval  and  resource  subject  to  the  shift  policy  is  assigned 
an  authorized  level  in  the  Shift  Table  data.  Figure  12  illustrates 
these  data  describing  the  shift  operation.  In  this  example,  there 
are  five  different  shift  intervals.  The  first  three,  each  8  hours 
long,  represent  the  three  normal  weekday  shifts.  The  last  two,  each 
24  hours  long,  represent  weekend  shifts  for  all  day  Saturday  and 
Sunday.  The  repetition  instructions  prescribe  the  application  of  the 
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first  three  shift  intervals  five  times  in  succession  to  represent  the 
five  weekdays.  Following  this,  shift  intervals  4  and  5  are  enacted 
to  represent  the  two  weekend  shifts.  Upon  completion  of  shift  interval 
5,  the  whole  pattern  is  repeated  for  the  following  week,  and  so  forth. 
For  each  shift  interval,  authorized  levels  are  given  for  each  affected 
resource.  Resource  C,  for  example,  might  represent  a  maintenance 
specialty  with  3,  4,  and  9  men  authorized  for  the  respective  weekday 
shifts,  9  men  for  all  day  Saturday,  and  none  for  Sunday. 


REPETITION'  INSTRUCTIONS: 

SHIFT  INTERVALS: 

SHIFT  DURATIONS: 

AUTHORIZED 
RESOUPCE  LEVELS: 


1 

2 

3 

S 

8 

8 

hours 

hours 

hours  i 

A 

10 

8 

6 

B 

5 

5 

5 

C 

3 

4 

9 

D 

8 

8 

6 

E 

4 

2 

0 

THEN  DO 


TIME 


4 

5 

_ 

1 

24  ; 

24 

hours  i 

i 

hours 

5 

0 

00 

2 

9 

0 

5 

0 

6 

0 

Fig. 


12  --  Example  shift  policy  data 


Whereas  a  shift  pattern  similar  to  Fig.  12  might  apply  to  main¬ 
tenance  personnel,  different  patterns  might  be  defined  for  other  kinds 
of  resources.  For  example,  the  shift  pattern  in  Fig.  13  might  apply 
to  aircraft  in  the  simulation.  In  this  example,  the  authorized 
strength  for  aircraft  type  A  is  10  during  the  first  four  weeks,  and 
18  thereafter.  The  authorized  level  for  aircraft  type  B  starts  at 
5,  builds  up  to  20  in  the  fourth  week,  and  remains  at  20  thereafter. 
The  authorized  number  of  aircraft  type  C  is  18  except  that  every  third 
week  after  the  first  four  weeks  9  are  withdrawn  for  some  other  duty. 
This  shift  policy,  although  structurally  the  same  as  that  illustrated 
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in  Fig.  11,  indicates  the  kinds  of  complexities  that  shift  procedures 
can  encompass  with  respect  to  resource  availability.  A  variety  of 
such  shift  policies,  each  applicable  to  a  prescribed  set  of  resources, 
may  operate  simultaneously  during  the  simulation. 

Whenever  a  shift  change  occurs  for  a  given  resource,  the  resource 
level  will  be  either  increased,  decreased,  or  left  the  same,  as  pre¬ 
scribed  by  the  authorized  levels  in  the  shift  tables.  The  shift 

REPETITION  INSTRUCTIONS:  DO  |  i  |tIME;  THEN  DO  99  TIMES 


Fig.  13  —  Example  shift  policy  data  for  airplanes 


change  procedure  takes  no  action  if  the  level  remains  the  same.  If 
it  is  increased,  the  on-hand  balance  for  the  resource  is  appropriately 
increased  and  the  task  completion  procedure,  as  previously  described, 
is  applied;  the  additional  amounts  gained  by  the  shift  change  are 
logically  equivalent  to  the  resources  released  by  a  completed  task. 

The  task  completion  procedure  determines  whether  there  are  backordered 
tasks  for  the  resource  and,  if  so,  as  many  as  possible  with  the  addi¬ 
tional  resource  supply  provided  by  the  shift  change. 

If  the  resource  level  is  decreased,  a  check  is  made  to  determine 
whether  enough  of  the  resource  is  on-hand  (not  being  used  by  tasks) 
to  provide  the  decrement.  If  so,  the  on-hanc  balance  is  correspondingly 
reduced  and  no  further  action  is  taken.  However,  if  part  or  all  of 
the  reduction  cannot  be  taken  from  on-hand  assets,  the  required  amount 
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BEST  AVAILABLE  COPT 


must  be  recovered  from  Casks  in  process  that  are  using  the  resource. 

The  recovery  procedure  inspects  the  completion  times  of  in- 
process  tasks  using  a  resource.  Tasks  that  will  finish  within  a 
specified  time  ate  permitted  to  continue,  and  the  resources  they  use 
are  considered  as  satisfying  part  or  all  of  the  amount  to  be  recovered. 
The  time  allowed  depends  upon  the  priority  group  to  which  the  task 
belongs;  higher  priority  tasks  may  be  permitted  to  continue  longer 
than  lower  priority  ones.  This  procedure  is  designed  to  represent 
an  overtime  policy,  wherein  resources  such  as  maintenance  personnel 
are  permitted  to  temporarily  exceed  their  authorized  levels.  When 
casks  subject  to  the  overtime  policy  finish,  appropriate  amounts  of 
the  released  resources  are  used  to  satisfy  the  reduction  in  levels 
corresponding  to  the  new  shift. 

If  the  resource  level  reductions  are  not  fully  satisfied  by  the 
overtime  policy,  tasks  are  preempted  (interrupted)  in  order  to  recover 
the  needed  amounts.  Lowest  priority  tasks  are  preempted  first  and 
placed  in  a  backorder  status  until  the  released  resources  satisfy 
the  shift  reduction  requirements.  These  tasks  will  be  restarted 
when  resources  become  available  either  through  completion  of  other 
tasks  or  by  increases  in  levels  caused  by  a  later  shift  change. 

In  general,  the  shift  change  procedure  is  similar  to  the  task 
start  and  completion  procedures,  in  that  it  also  needs  resources  when 
released.  The  overtime  policy  of  the  shift  change  procedure  is  anal¬ 
ogous  to  the  expedited  repair  policy  of  the  task  start  procedure.  The 
main  difference  is  that  substitutes  are  not  involved  in  the  shift 
change  procedures,  whereas  they  are  important  in  the  task  start  and 
completion  procedures. 

PEFFORMAUCF  SUWAM_  P.EPOPT 

The  Performance  Summary  Report  is  the  primary  output  of  the  simu¬ 
lation  program.  It  contains  65  overall  performance  statistics  divided 
into  the  following  functional  groups: 

Operations 

Aircraft 

Personnel 

Shop  Repair 

Supply 

Equipment 


Referring  Co  Che  example  in  Fig.  14,  chere  is  one  row  of  data 
for  each  of  Che  65  aeaciscics.  Aside  from  Che  "TOTAL"  column,  the 
columnar  readings  may  be  different  for  each  of  the  six  groups.  In 
fact,  the  user  can  control  (on  Input  Form  10 — Performance  Summary 
Report)  what  is  printed  as  columnar  headings  and  the  meaning  of  the 
data  under  them,  within  certain  limits. 

In  general,  statistics  are  accumulated  during  the  simulation  and 
assigned  to  a  particular  column  of  the  report  according  to  parameter 
value.  Generally,  the  parameter  is  a  column  number  assigned  to  each 
resource  item  in  the  Resource  Table.  If,  for  example,  the  user  wants 
the  columns  for  the  supply  portion  of  the  report  to  represent  group¬ 
ings  by  the  first  digit  of  a  part  identifier  code,  he  assigns  each 
supply  item  a  column  number  under  which  the  item's  supply  statistics 
are  to  be  accumulated.  If  unit  cost  or  demand  rate  categories  are 
desired,  then  the  appropriate  category  number  may  be  assigned  to  each 
supply  item,  causing  its  statistics  to  be  accumulated  and  presented 
in  the  corresponding  column  of  the  report. 

Similar  procedures  apply  to  the  other  groups  of  statistics.  Man¬ 
power  statistics  may  be  grouped  by  shop  (as  illustrated  in  the  example), 
by  skill  type,  by  AFSC  groupings,  and  so  forth.  Aircraft  statistics 
may  be  distributed  by  squadron  and  by  aircraft  type,  for  example. 
Possibilities  of  these  kinds  are  limited  only  to  the  extent  that  re¬ 
source  items  can  be  assigned  to  columns  of  the  report.  There  is  no 
limit  on  the  number  of  columns  that  may  be  used,  except  that  imposed 
by  the  computer  storage  capacity.  If  more  than  ten  columns  are  used, 
the  remaining  colimma  will  appear  on  successive  pages. 

The  main  exception  to  this  procedure  is  the  Operations  group 
statistics.  Here,  only  mission  type  controls  the  columnar  split-out. 

The  user,  however,  may  still  define  mission  types  as  he  pleases  and 
label  the  column  headings  to  correspond. 

For  any  given  run  of  the  simulation  program,  the  Performance 
Summary  Report  may  be  produced  in  two  levels .  The  Level  I  reports 
are  produced  on  a  periodic  basis  as  specified  by  the  user:  every 
day,  every  other  day,  every  veek,  etc.  Statistics  in  this  report 
represent  performance  during  the  indicated  period.  The  Level  IT 
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reports  are  produced  for  a  piven  multiple  of  the  Level  I  reports  and 
contain  summary  statistics  over  a  longer  period.  Thus,  Level  I 
reports  may  be  produced  each  day,  with  Level  II  reports  being  produced 
weekly;  or  Level  I  reports  may  appear  weekly,  with  Level  II  reports 
containing  monthly  summaries.  Level  II  and  Level  I  formats  are  iden¬ 
tical. 

OTHER  OUTPUT  REPORTS 

When  requested  by  appropriate  entries  on  Form  1  (Run  Specifica¬ 
tions)  ,  the  simulation  program  can  produce  one  or  more  of  the  follow¬ 
ing  output  reports: 

Resource  Status 
Mission  Status 
In-Process  Status 
Backorder  Status 
Diagnostic 

The  first  four  reports  contain  data  representing  the  status  of  the 
simulated  environment  at  particular  points  in  simulated  time  as 
specified  by  the  user  on  Form  1.  The  last  report  (Diagnostic)  is 
used  by  a  programmer  or  experienced  user  of  the  model  as  an  aid  in 
locating  suspected  malfunctions  of  the  model.  It,  in  effect,  lists 
data  for  each  transaction  that  occurs  between  two  points  in  simula¬ 
tion  time,  as  specified  on  Form  1. 
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Fig.  14  —  Example  of  performance  sunmary  report 
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V.  EMBEDDED  DECI S ION  MODEL 


In  general,  a  simulation  model  can  only  be  used  to  evaluate  a 
particular  study.  The  input  data  describe  the  actual  or  hypothetical 
environments  and  operating  conditions;  the  output  data  provide  the 
consequences  of  the  assumed  operation  in  terms  of  performance,  re¬ 
source  utilization,  and  other  measures.  But  in  any  particular  run, 
the  simulation  model  cannot  arrive  at  decisions  or  produce  best  or 
preferred  solutions  to  a  particular  problem.  Only  through  a  carefully 
designed  sequence  of  runs,  Involving  controlled  changes  in  particular 
policy  variables,  can  preferred  solutions  be  approximated. 

To  help  alleviate  this  difficulty  and  to  reduce  the  number  of 
runs  required  for  certain  kinds  of  study  objectives,  a  special  pro¬ 
cedure  has  been  incorporated  in  the  Logistics  Composite  Model.  This 
section  describes  the  procedure,  a  mathematical  decision  model  of 
separate  subroutines  embedded  in  the  main  simulation  program. 

PURPOSE 

The  main  purpose  of  the  embedded  decision  model  is  to  help 
determine  a  best  mix  of  resources  to  support  a  prescribed  flying 
program  within  given  performance  tolerances.  More  specifically,  the 
model  changes  resource  levels  whenever  a  designated  performance 
measure  falls  to  an  unacceptable  level  during  a  simulation  run. 

Levels  are  altered  according  to  a  cost-effectiveness  criteria,  where 
resources  that  increase  system  performance  the  most  on  a  per  dollar 
basis  are  considered  first  for  increases  in  stockage. 

The  procedure  might  also  be  used  to  impose  an  overall  dollar 
constraint  ot>.  support  resources.  In  this  application,  the  decision 
model  would  be  used  to  determine  the  mix  of  resources,  within  the 
dollar  constraint,  that  maximizes  system  performance  for  a  given 
flying  program.  The  decision  model  reduces  the  number  of  simulation 
runs  that  would  otherwise  be  required  to  solve  this  problem. 

The  decision  process  consists  of  two  main  parts,  a  forecasting 
procedure  and  the  decision  model  itself.  These  features  are  optional 
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for  any  given  rim;  if  used,  however,  corresponding  forms  must  be  com¬ 
pleted  to  provide  input  data  needed  for  their  operation.  The  decision 
procedures  and  data  requirements  are  further  described  below. 

FORECASTING  PROCEDURE 

During  simulation,  a  variety  of  system  performance  statistics 
are  accumulated  and  output  as  a  periodic  performance  report.  Some 
of  these  statistics  have  been  specifically  designated  for  possible 
use  in  controlling  the  application  of  the  embedded  decision  model. 

In  particular,  the  following  performance  measures  have  been  selected 
for  this  purpose: 

Sortie  effectiveness  (sorties  accomplished  as  a  percentage 

of  sorties  requested) 

Average  aircraft  turnaround  time 

Average  number  of  sorties  per  aircraft  per  day 

These  measures  are  produced  periodically  during  the  simulation,  with 
the  period  being  fixed  at  one  day  for  most  runs.  If  daily  observa¬ 
tions  for  a  particular  statistic  such  as  sortie  effectiveness  are 
plotted  on  a  graph,  the  results  may  be  similar  to  those  shown  in 
Fig.  15. 

Data  like  those  in  Fig.  15  are  called  "Time  Series,"  and  can  vary 
considerably  from  day  to  day.  Since  the  decision  model  increases  the 
levels  of  critical  resources  whenever  the  designated  performance 
measure  falls  to  a  specified  point,  it  is  undesirable  to  react  to 
the  daily  fluctuations.  To  avoid  this,  the  fluctuations  are  "smoothed" 
by  a  forecasting  procedure. 

Each  period,  the  forecasting  procedure  estimates  the  performance 
measure  for  the  next  period,  using  data  observed  (produced  by  the 
simulation  model)  so  far.  These  forecasted  values  smooth  the  observed 
data;  when  plotted  on  a  graph  along  with  the  observed  data,  they  may 
appear  as  shown  in  Fig.  16. 

This  figure  also  shows  a  trigger  level  which  controls  the  decision 
model.  As  the  simulation  progresses,  the  decision  model  is  called 
into  operation  whenever  Che  fortoaattd  value  of  the  designated 
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Fig.  15  —  Example  of  a  time  series 


Fig.  16  —  Example  of  the  forecasting  procedure 

performance  measure  falls  to  the  trigger  level.  The  user  puts  in  the 
desired  trigger  levels  for  each  performance  measure  listed  above;  for 
any  given  run,  however,  the  only  operative  trigger  level  will  be  that 
for  the  particular  performance  measure  controlling  the  decision  process. 

Input  Form  30  (Forecast  Parameter  Specifications)  is  used  to 
identify  the  performance  measure  controlling  the  decision  process  and 
to  provide  values  for  the  trigger  levels  and  other  factors  used  in 
the  forecasting  procedure.  This  form,  with  example  entries,  is  illus¬ 
trated  in  Fig.  17. 


PERFORMANCE  MEASURE 


In  summary,  the  forecasting  procedure  smooths  out  the  short  term 

j 

fluctuations  in  designated  performance  data  in  order  to  prevent  the 
decision  model  from  raising  resource  levels  too  often.  More  specific 
features  of  the  forecasting  procedure  are  described  below. 

Time  Series  Models 

The  forecasting  procedure  is  based  upon  an  exponential  smoothing 
technique,  in  which  the  observed  data  are  assumed  to  represent  random 
fluctuations  caused  by  an  underlying  process  called  a  time  series 
model.  The  kinds  of  time  series  models  used  by  the  forecasting  pro¬ 
cedure  are  a  constant  model,  a  linear  model,  and  a  quadratic  model, 
illustrated  in  Figs.  18a,  18b,  and  18c,  respectively. 

In  the  constant  time  series  model  (Fig.  18a),  it  is  assumed  that 
no  real  change  in  the  observed  data  is  expected;  only  random  fluctua¬ 
tions  about  some  constant  value.  In  the  linear  model,  a  trend  is 

I 

expected — it  may  be  upward,  as  shown  in  Fig.  18b,  or  downward.  In 
either  case,  the  observed  data  over  time  are  assumed  to  represent  ran¬ 
dom  fluctuations  about  the  upward  or  downward  sloping  line.  In  the 
quadratic  model,  an  upward  (or  downward)  trend  is  expected,  but  at  an 
Increasing  (or  decreasing):  rate.  Again,  the  observed  data  would  be 
random  variations  about  a  curve  like  that  shown  in  Fig.  18c. 


Fi'gs.  18a,  b,  and  c  --  Time  series  models 
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Only  one  time  series  model  applies  to  a  statistic  processed  by 
the  forecasting  procedure  for  any  given  period.  However,  the  pro¬ 
cedure  may  automatically  switch  froQ  one  model  to  another  during 
simulation,  depending  upon  the  nature  of  the  observed  data.  For 
example,  a  statistic  such  as  mission  effectiveness  may  be  subject  to 
the  constant  model  to  start  with.  Then,  as  the  simulation  progresses, 
a  downward  trend  may  occur.  The  forecasting  procedure  detects  this 
trend  from  the  observed  data  and  if  it  appears  significant,  automati¬ 
cally  causes  a  change  from  the  constant  model  to  a  linear  model.  Using 
the  linear  model,  then,  a  better  forecast  will  result  since  the  trend 
will  now  be  explicitly  considered.  Similarly,  a  switch  to  a  quadratic 
model  may  be  made  if  a  significant  change  in  trend  is  detected.  If 
later  in  the  simulation,  a  trend  or  change  in  trend  is  no  longer  pres¬ 
ent,  the  forecasting  procedure  will  switch  back  to  a  lower  order  time 
series  model.  This  switching  feature  applies  to  each  system  perfor¬ 
mance  measure  independently. 

Filtering 

Unusual  observations  of  the  statistic  being  forecast  are  par¬ 
tially  rejected  for  consideration  in  the  forecasting  procedure.  This 
is  illustrated  in  Fig.  19,  where  the  shaded  areas  represent  the  ob¬ 
served  data  that  are  rejected.  In  this  example,  the  underlying  time 
series  model  is  assumed  constant.  The  dashed  lines  represent  upper 
and  lower  limits  for  accepting  the  observations.  The  user  may  change 
these  limits  to  reject  more  or  less  of  the  observed  data  as  he  desires. 

The  filtering  procedure  prevents  the  forecasting  procedure  from 
over-reacting  to  occasional  or  sporadic  data  observations  of  an  un¬ 
usual  nature.  These  unusual  situations  may  be  caused  by  a  particular 
combination  of  random  events  occurring  during  the  simulation  and  may 
be  unrepresentative  of  the  general  processes  being  simulated. 

Accelerated  Smoothing 

During  simulation,  the  observed  data  may  show  a  sudden  upward 
or  downward  jump  or  step.  For  example ,  mission  requirements  may 
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In  this  example,  the  sudden  drop  occurs  in  period  6,  where  the 
observed  da‘a  drop  below  the  previously  applicable  filtering  limits. 

The  forecasting  procedure  detects  this  kind  of  change  by  keeping  track 
of  the  number  of  times  the  filtering  limit  has  been  exceeded.  When 
the  observed  data  exceed  the  filtering  limit  twice  in  a  row,  it  is 
assumed  that  this  does  not  occur  by  chance  (since  the  probability  of 
it  happening  by  chance  is  quite  small),  but  Indicates  that  a  true 
alteration  of  the  underlying  process  has  occurred. 

When  a  change  of  this  kind  is  detected,  the  forecasting  procedure 
automatically  switches  to  "accelerated"  smoothing.  In  effect,  a 
smoothing  constant,  used  in  the  forecasting  procedure  to  control  the 
forecast's  responsiveness  to  observed  data,  is  greatly  increased  ao 
that  more  recent  data  will  have  a  much  greater  influence  upon  the 
forecast  than  older  data.  In  this  way,  the  forecast  "homes  in"  on 
the  new  situation  faster  than  it  otherwise  would.  When  the  accelerated 
smoothing  is  no  longer  needed,  the  smoothing  constant  changes  back  to 
its  former  value.  This  feature  applies  when  the  statistic  is  governed 
by  a  linear  or  quadratic  time  series  model  as  well  as  by  the  constant 
model  illustrated  in  Fig.  20. 

Time  of  Start 

For  any  given  simulation  in  which  the  forecasting  procedure  is 
applied,  the  user  may  specify  the  simulation  time  at  which  the  model 
first  becomes  operative.  This  may  be  time  zero  or  any  time  thereafter. 

This  feature  enables  the  user  to  skip  over  the  first  few  periods 
of  the  simulation  where  the  results  are  usually  not  valid  because  of 
the  way  the  data  are  initialized.  For  example,  the  simulation  starts 
with  all  resources  available  up  to  their  authorized  allowances.  Until 
jobs  occur  to  use  the  resources,  the  performance  statistics  will  be 
unrealistic  and  should  not  be  used  in  the  forecasting  procedure.  The 
simulation  will  usually  "settle  down"  after  a  few  simulated  days,  at 
which  time  the  forecasting  procedure  may  be  applied. 


—  I 


-62- 


Floor 

The  forecasting  procedure*  has  a  number  called  Che  "floor"  which 
Is  sec  by  Che  user  Co  always  keep  Che  forecasced  sCadsCics  above 
Chae  value.  Whenever  a  daCa  observation  falls  below  Che  floor,  Che 
floor  iCself  is  subsdcuced  for  Che  observacion,  thereby  always  pro¬ 
ducing  a  forecast  above  chia  value. 

DECISION  MODEL 

During  simulation,  Che  forecasting  procedure  may  determin  that 
a  designated  performance  measure  has  reached  a  critical  or  "trigger" 
level,  representing  e  lower  bound  for  acceptable  performance.  Ac 
this  Claw,  Che  decision  model  is  called  into  operation  in  order  Co 
relieve  Che  situation  and  co  bring  Che  performance  measure  back  to 
acceptable  values.  The  decision  model  accomplishes  this  by  raising 
authorized  levels  of  Che  resource  items  causing  the  most  trouble. 

For  Che  decision  model  co  determine  what  resource  items  are  most 
likely  causing  Che  drop  in  system  performance,  a  measure  is  defined 
for  each  item  indicating  how  well  it  is  meeting  requirements .  The 
derivation  of  this  measure,  or  "utilization  index,"  may  be  explained 
by  referring  to  Fig.  21,  in  which  the  belance  of  a  particular  item  is 
plotted  es  a  function  of  simulated  time.  Positive  values  indicate 


Fig.  21  —  Utilization  Index 
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chat  supply  of  Che  Item  Is  larger  Chan  demand.  Negative  values  in¬ 
dicate  due-outs — Instances  where  demand  has  exceeded  the  available 
supply. 

If  a  particular  interval  is  defined,  as  indicated  by  the  vertical 
dashed  lines  in  Fig.  21,  then  the  area  under  the  balance  graph,  in¬ 
dicated  by  shading  in  Fig.  21,  may  be  computed.  If  this  area  is 
positive,  then  the  item  is  in  a  relatively  good  position  with  respect 
to  meeting  requirements.  If  the  area  is  negative,  it  indicates  that 
the  item  is  falling  to  meet  requirements.  This  area,  divided  by  the 
number  of  demands  during  the  period,  represents  the  item's  utiliza¬ 
tion  index. 

For  each  resource  item,  then,  the  utilization  index  is  computed 
each  period.  This  index  may  vary  considerably  from  one  period  to 
another,  perhaps  fluctuating  between  negative  and  positive  over  simu¬ 
lated  time.  When  the  decision  model  is  called  into  operation,  it 
may  happen  chat  an  item  is  in  serious  trouble  (large  negative  value 
of  the  utilization  index)  at  that  time  by  sheer  chance  and  that,  nor¬ 
mally,  the  supply  of  the  item  can  meet  requirements.  To  prevent  the 
decision  model  from  reacting  to  these  short-term  fluctuations,  the 
item  utilization  indices  are  therefore  smoothed  by  a  simplified  ver¬ 
sion  of  the  technique  used  by  the  forecasting  procedure.  This  version 
performs  single  exponential  smoothing  only,  where  the  underlying  time 
series  model  is  assumed  constant. 

The  decision  model,  then,  uses  the  smoothed  values  of  the  utili¬ 
zation  indices  in  determining  which  items  are  "in  trouble"  and  pre¬ 
sumably  degrading  overall  system  performance.  The  indices  themselves, 
however,  are  only  one  kind  of  factor  the  decision  model  uses  in  de¬ 
termining  which  resource  items  to  augment  and  by  how  much.  Another 
factor  is  the  cost  of  adding  one  unit  of  the  resource  to  the  available 
inventory.  If  two  resource  items  have  the  same  utilization  index, 
but  one  is  cheaper  than  the  other,  the  decision  model  will  add  a  unit 
of  the  cheaper  item  to  the  Inventory  if  a  choice  must  be  made,  since 
the  same  increase  in  system  performance  may  be  expected  at  less  cost. 

In  general,  the  decision  model  determines  which  items  should 
have  their  levels  increased  according  to  a  "utility  measure,"  computed 
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as  an  exponential  function  of  the  utilization  index  for  each  item 
divided  by  its  unit  cost.  In  addition,  the  decision  model  allows  for 
the  fact  that  the  second,  third,  fourth,  etc.,  units  added  to  the 
inventory  of  a  given  item  will  be  of  successively  less  value  with 
respect  to  increasing  overall  system  performance.  This  factor  is 
considered  by  multiplying  the  utility  measure  for  the  first  added 
unit  by  a  fraction  to  obtain  a  utility  measure  for  the  second  added 
unit;  this  in  turn  is  multiplied  by  the  same  fraction  to  obtain  a 
utility  measure  for  the  third  added  unit,  and  so  forth,  as  illustrated 
in  Pig.  22.  In  this  figure,  the  fraction  used  to  obtain  the  utility 


NUMBER  OF  UNITS  ADDED  TO  INVENTORY 

Fig.  22  —  Utility  measures  for  additional  units  of  an  Item 


measures  is  one-half.  The  user  may  adjust  the  fraction,  however,  to 
obtain  different  relative  values  for  successively  larger  amounts  added 
to  the  inventory  of  a  resource  item. 

Having  computed  the  utility  measure  for  each  resource  item  and 
for  each  unit  that  might  be  added  to  Inventory,  the  decision  model 
then  ranks  all  the  measures  from  highest  to  lowest.  The  results  might 
be  as  shown  below.  Vith  this  example,  the  decision  model  would  first 
increase  the  level  of  resource  5  by  1  unit,  then  resource  8  by  1  unit, 
then  resource  2  by  1  unit,  then  resource  5  by  a  second  unit,  and  so 
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Resource  No.  Unit 


Utility  Measure 


5  1  2.3 

8  1  2.2 

2  1  1.9 

5  2  1.8 

3  1  1.5 

1  1  .9 

8  2  .3 

7  1  .1 

5  3  .05 

6  1  .02 


on,  working  down  the  list  in  succession.  Since  the  utility  measure 
indicates  the  relative  "worth"  of  an  additional  unit  of  resource, 
with  respect  to  increasing  system  performance,  units  with  highest 
values  are  assigned  first,  followed  by  units  with  successively  lower 
values.  Input  Form  40  (Decision  Model  Factors)  provides  factors  that 
the  decision  model  uaes .  This  form,  with  example  entries,  is  illus¬ 
trated  in  Fig.  23. 

In  summary,  the  decision  model  determines  which  resource  items 
are  in  the  most  trouble  per  dollar  of  additional  inventory  investment 
and  incre.ises  their  levels.  The  simulation  model  then  operates  with  the 
increased  levels  with  the  expectation  that  the  degraded  system  per¬ 
formance  will  now  be  alleviated.  More  specific  features  of  the 
decision  model  are  described  below. 


Shift  Changes 

If  a  resource  such  as  manpower  is  subject  to  shift  changes, 
whereby  authorized  levels  are  changed  over  time,  the  decision  model 
treats  each  different  shift  for  each  such  resource  as  a  separate 
resource  item.  By  so  doing,  the  model  can  detect  which  shifts  are 
causing  problems  with  respect  to  resource  availability  and  cause 
levels  to  be  raised  on  a  shift  basis.  For  example,  the  night  shift 
for  a  particular  shop  may  have  inadequate  manning,  in  which  case  the 
decision  model  may  increase  the  authorized  level,  leaving  the  day 
shifts  unchanged  if  they  are  adequately  manned. 


StCTtON  B  -  OtCISION 

LOGISTICS  COMPOSITE  MODEL  rout m  -  mcision 


Fig.  23  —  Example  of  Input  Form  40 
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Inveatment  Batch 

Each  time  the  decision  model  is  called  into  operation,  the  levels 
of  some  resource  items  are  raised.  The  user  may  control  the  aggregate 
amount  of  increase,  in  terms  of  total  dollars,  by  specifying  an  in¬ 
vestment  batch  size  on  the  appropriate  input  form.  If,  for  example, 
an  investment  batch  of  $10,000  is  specified,  the  decision  model  will 
add  items  to  Inventory  up  to  a  total  of  $10,000  worth  and  no  more. 

In  general,  the  smaller  the  batch  size  is,  the  more  often  one  may 
expect  the  decision  model  to  be  called  into  operation.  If  the  batch 
size  is  set  too  high,  however,  excess  inventories  may  result. 

Item  Scaling  Constant 

When  values  of  the  utilization  index  are  computed  across  all 
items,  they  will  range  from  some  negative  value  to  some  positive 
value,  e.g.,  from  -2  to  +2.  In  deriving  the  utility  measure,  however, 
the  utilization  index  is  divided  by  the  item's  unit  cost.  The  unit 
coats  across  items  may  range  from,  say,  $100  to  $100,000.  For  the 
allocation  procedure  to  work  properly,  the  utilization  indices  must 
be  converted  so  that  they  will  be  spread  out  over  about  the  some  range 
of  values  as  the  unit  costa.  This  is  accomplished  by  using  an  expo¬ 
nential  function  that  contains  a  scaling  factor  for  multiplying  the 
utilization  index.  Since  the  value  for  this  "item  scaling  constant" 
depends  upon  typical  ranges  for  the  utilization  indices  and  unit 
costs,  several  operational  runs  of  the  Logistics  Composite  Model  must 
be  made  before  it  can  be  determined.  Once  it  has  been  determined, 
however,  it  will  probably  not  be  necessary  to  alter  it  in  subsequent 
uses . 

Unit  Sealing  Constant 

A a  described  above,  a  constant  fraction  is  used  to  calculate 
values  of  the  utility  measure  for  successive  units  of  an  item  to  be 
added  to  Inventory.  This  fraction  is  controlled  by  a  "unit  scaling 
constant"  that  the  user  may  adjust.  As  in  the  case  of  the  item 
scaling  factor,  however,  analysts  may  determine  an  appropriate  value 


for  this  constant  from  early  operational  runs  and  then  use  the  value 
for  subsequent  uses  of  the  model. 


Lender  Limit  for  Utility  Measure 

A  feature  of  the  decision  model  is  that  items  that  meet  require¬ 
ments  fairly  well  may  not  be  considered  in  the  procedure  for  raising 
levels.  The  user  may  input  a  number  to  represent  a  lower  limit  on 
the  values  of  the  utility  measure  that  are  used. 

Referring  to  the  tabulation  on  page  65,  for  example,  the  lower 
limit  may  be  set  to  0.1,  in  which  case  the  last  two  items  on  the  list 
(the  third  unit  of  resource  Ho.  5  and  the  first  unit  of  resource  No. 

6)  will  not  be  considered  for  inventory  augmentation;  in  general,  any 
unit  of  a  resource  with  a  utility  measure  less  than  0.1  will  be  re¬ 
jected  in  this  case.  As  in  the  case  of  the  scaling  factors,  this 
lower  limit  may  require  some  initial  experimentation  to  find  an  appro¬ 
priate  value. 

OUTPUT  .REPORTS 

At  the  option  of  the  user,  output  reports  showing  results  of  the 
forecasting  procedure  and  decision  model  may  be  produced  each  time 
these  routines  are  exercised.  Examples  of  these  reports  are  shown 
in  Pig.  24. 

The  forecasting  report  is  divided  into  two  sections.  Section  I 
contains  the  observed  data  during  the  previous  forecasting  period, 
the  forecasts  from  the  previous  computations,  and  the  new  forecasts. 
Section  II  contains  values  for  various  parameters  used  in  the  forecast 
computations;  these  will  interest  only  the  analyst  investigating  the 
behavior  of  the  forecasting  procedure. 

The  output  report  for  decision  model  results  lists  units  added 
to  inventory  ranked  according  to  their  utility  measures.  For  each 
unit  added,  various  data  elements  are  printed  out  as  illustrated  in 
Fig.  24.  At  the  top  of  the  report,  assigned  values  for  decision 
model  parameters  are  shown  for  reference  purposes. 


Fig.  24  —  Example  outputs  of  the  forecasting  procedure  and  decision  model 


VI .  POSTPROCESSOR 


During  simulation  It  is  possible  to  generate  a  large  amount  of 
detailed  data  representing  simulation  results.  The  data  may  then  be 
combined,  summarized,  and  consolidated  into  output  reports  of  various 
kinds.  In  many  large  simulation  models,  data  generated  during  the 
simulation  are  processed  afterward  by  a  separate  program  called  a 
postprocessor  to  obtain  the  summary  reports. 

In  the  Logistics  Composite  Model,  the  simulation  program  itself 
produces  the  main  summary  results  as  it  operates.  However,  there  is 
also  a  separate  postprocessor  that  produces  certain  ancillary  product 
This  program  is  further  described  here. 

PURPOSE 

Summary  results  produced  during  the  simulation  reflect  the  be¬ 
havior  and  status  of  the  simulated  environment  during  discrete  time 
intervals  or  at  specific  points  in  time  in  accordance  with  the  re¬ 
porting  interval.  To  obtain  results  over  the  entire  simulation,  a 
number  of  output  reports  must  be  inspected.  This  is  the  function  of 
the  postprocessor  in  the  L-COM  model — to  develop,  in  a  single  product 
selected  summary  statistics  over  the  entire  simulation.  In  effect, 
it  consolidates  the  periodic  reports  produced  during  the  simulation. 
It  also  produces  aircraft  status  information  as  a  function  of  simu¬ 
lated  time  rather  than  at  specific  points  in  time  as  output  during 
the  simulation. 

More  specifically,  the  postprocessor  produces  two  kinds  of  out¬ 
put  products  showing  simulation  results  as  functions  of  simulation 
time.  These  are  the  summary  statistics  and  the  aircraft  displays, 
both  in  graphical  form,  which  are  described  below. 

SUMMARY  STATISTICS 

Preprocessor  output  consists  of  selected  summary  statistics  that 
the  computer  plots  in  graphical  form  as  functions  of  simulation  time. 
Statistics  produced  in  this  manner  are  selected  from  among  those 
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contained  in  the  performance  summary  report  produced  during  the 
simulation.  Thus,  such  summary  statistics  may  be  displayed  as  a 
percentage  of  sorties  accomplished,  average  aircraft  turnaround  time, 
personnel  utilization  percentage,  supply  fill  rate,  equipment  utiliza¬ 
tion  percentage,  and  othera. 

Each  statistic  selected  for  display  in  this  form  is  plotted  on 
a  separate  page,  as  illustrated  in  Fig.  25.  Although  the  graph  for 
each  statistic  has  simulation  time  as  the  abscissa,  the  ordinate  may 
be  scaled  according  to  the  particular  statistic  involved. 

These  graphs  enable  a  user  to  discern  how  the  simulated  environ¬ 
ment  changes  over  time.  They  also  help  detect  functional  interactions 
such  as  the  way  in  which  aircraft  NORS  rates  change  as  supply  fill 
rates  decrease  or  increase. 


AIRCRAFT  DISPLAYS 


Another  type  of  display  the  postprocessor  generates  is  a  plot, 
for  selected  aircraft,  of  the  various  tasks  incurred  during  the  simu¬ 
lation.  This  display  shows  not  only  tasks  involving  the  airplane, 
but  also  shop  repair  tasks  for  components  removed  from  the  airplane. 

An  example  of  this  type  of  display  is  shown  in  Fig.  26.  Each  task  is 
represented  in  a  separate  line ,  arranged  in  chronological  sequence 
according  to  start  time  in  decimal  days.  The  duration  of  the  task  is 
represented  by  a  contiguous  sequence  of  alphabetic  letters  which  also 
identify  the  kind  of  task.  The  meanings  of  these  symbols  are  as  follows: 


Symbol 


Definition 


V 

F 

S 

U 

B 

D 

L 


Service  task 
Actual  flight 

Aircraft  scheduled  maintenance 
Aircraft  unscheduled  maintenance 
Off-equipment  actions 
Depot  actions 
Imposed  delays 


Tnese  displays  are  useful  in  verifying  that  airplanes  and  com¬ 
ponents  in  the  simulation  do  undergo  processes  that  approximate  real- 
world  ones  in  terms  of  kinds  and  sequence  of  tasks.  They  also  show 
visually  how  some  logical  functions  of  the  model  operate.  For  example, 


CIUTH  Of  STAT( It)  •AVEIUCC  SiMTItt/  A/C  /  OAT 

MEAN  VALUE  FROM  DAY  I)  OH  It  I.IOi  STANOAAO  OCVIATIQM 


BAY 

Fig.  25  --  Example  summary  statistic  graph 
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if  a  task  Is  preempted  and  finished  at  a  later  time,  it  will  show  up 
in  the  display  as  an  interrupted  sequence  of  symbols.  The  frequency 
and  duration  of  such  interruptions  provide,  at  a  glance,  a  general 
idea  of  resource  scarcities  at  this  point  in  simulation  time.  In 
general,  however,  these  displays  have  limited  value  in  deriving  over¬ 
all  conclusions  from  the  simulation,  since  they  are  produced  only 
for  a  sample  of  airplanes,  each  being  subject  to  random  processes 
insofar  as  information  in  the  display  is  concerned. 


VII.  OPERATING  CHARACTERISTICS 


To  a  large  extent,  the  practical  value  of  a  simulation  model  is 
determined  by  how  easy  it  io  to  use,  the  size  of  problem  it  can  accept, 
the  amount  of  computing  time  it  requires,  and,  in  some  cases,  hov  readily 
it  can  be  transferred  from  one  type  of  computer  to  another.  In  this 
section,  the  degree  to  which  the  Logistics  Composite  Model  satisfies 
these  practical  considerations  is  discussed. 

MODES  OF  OPERATION 

In  using  L-COM,  the  first  and  most  difficult  step  is  to  develop 
the  inputs.  Assuming  data  have  not  previously  been  established  for 
this  purpose,  the  data  development  program  begins  by  constructing  task 
networks  that  represent  the  processes  of  interest.  The  largest  prob¬ 
lem  here  is  assessing  the  level  of  detail  needed  to  obtain  valid  re¬ 
sults.  If  too  much  detail  is  included,  requirements  for  data  collec¬ 
tion,  computer  memory  capacity,  and  computer  running  times  can  become 
excessive.  If  insufficient  detail  is  included,  valid  results  for  the 
study  objectives  may  not  be  obtained.  The  only  general  guidance  we 
can  offer  is  that  the  task  networks  should  include  as  few  tasks  as 
possible — those  which  account  for  most  of  the  resource  utilization. 

Once  the  task  networks  are  established  and  appropriately  labeled, 
further  data  for  identified  tasks  can  be  obtained.  As  part  of  this 
data,  resource  requirements  for  each  task  must  be  determined.  Having 
identified  required  resources,  the  remainder  of  the  resource  data  may 
be  collected.  Next,  data  pertaining  to  the  failure  mechanism  may  be 
obtained  according  to  relationships  between  tasks  causing  failures 
and  affected  resources.  Following  this,  data  for  generating  mission 
requirements  may  be  established  and  initial  entry  points  into  the  task 
networks  can  be  Identified.  Finally,  shift  policies  and  associated 
data  can  be  established,  as  well  as  decision  model  parameters,  report 
specifications,  and  other  miscellaneous  data  elements  the  model  needs. 

Having  established  an  initial  data  base  using  the  prescribed 
forms,  the  user  may  transcribe  the  data  to  punched  cards  and  input  it 


Co  Che  preprocessor.  According  Co  error  messages  and  ocher  prepro¬ 
cessor  outputs,  pordons  of  Che  daca  may  require  correcclon  and 
several  preprocessor  runs  may  be  necessary  before  a  valid  sec  of  daca 
is  obcained  for  use  by  Che  simulacion  program. 

Wieh  Che  daCa  base  now  escablished,  Che  main  simulacion  may  be 
run  a  number  of  Cimes,  wich  porcions  of  Che  daca  such  as  sCock  levels, 
cask  seleccion  faccors,  or  ocher  policy  paramecers  being  changed  be- 
Cveen  runs  according  Co  scudy  objeccives.  This  procedure  is  furcher 
illusCraCed  in  Fig.  27.  For  each  run,  opCions  may  be  specified  wich 
regard  Co  oucpuc  produces,  Che  use  of  Che  forecasCing  procedure  and 
decision  model,  and  Che  use  of  Che  posCprocessor  funedons. 

According  Co  overall  sCudy  objectives,  chis  procedure  may  be 
repeated  several  times  for  different  data  bases.  Since  only  certain 
parts  of  Che  input  data  can  be  changed  for  different  runs  of  the  simu¬ 
lation  model,  changes  in  remaining  porcions  will  require  a  rerun  of 
the  preprocessor.  Although  the  preprocessor  does  not  require  exces¬ 
sive  computer  time,  the  whole  effort  of  making  changes  and  running 
the  preprocessor  until  a  consistent  and  valid  sec  of  data  is  obtained 
can  become  considerable  and  should  be  avoided  as  much  as  possible.. 

The  procedure  outlined  above  represents  the  model's  normal  operat¬ 
ing  mode.  For  certain  purposes,  other  modes  are  possible;  for  example, 
the  preprocessor  can  be  bypassed  altogether  by  preparing  input  data 
directly  in  the  required  formats.  Such  operations,  however,  require 
complete  familiarity  with  the  programming  aspects  of  the  model. 

COMPUTER  REQUIREMENTS 

The  main  computer  requirements  for  the  practical  use  of  the  L-COM 
model  are  that  a  SIKSC3IPT  compiler  must  be  available  for  the  computer 
type  being  considered,  and  chat  it  have  available  internal  storage  of 
at  least  the  equivalent  of  65,000  words,  36  bits  in  length.  In  addi¬ 
tion  to  the  11NIVAC  1107,  upon  which  the  model  is  currently  operating, 
a  variety  of  other  computers  may  be  used.  As  discussed  below,  the 
problems  involved  in  changing  from  one  computer  type  to  another  are 
relatively  small,  as  long  as  the  above  criteria  are  satisfied. 


INPUT 

•  Resource  Availability 

Supply  -  Kits 
Maintenance  -  UMD 
AGE 

•  Resource  Requirements  by 
Maintenance  Tasks 

Spares 

Personnel 

AGE 

•  System  Data 

NRTS  Rates 
Failure  Rates 


Operation  Data 
•  Daily  Requirements: 
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MODEL  CAPACITY 


The  largest  problem  that  can  be  run  on  a  given  computer  depends 
upon  the  capacity  of  its  internal  (core)  memory,  since  the  model  is 
designed  to  operate  totally  in  internal  memory.  Of  the  three  parts 
of  the  model,  the  main  simulation  program  has  the  most  stringent 
memory  requirements;  it,  therefore,  controls  the  size  of  problem  that 
can  be  run. 

Using  the  UNIVAC  1107  for  illustrative  purposes,  the  allocation 
of  memory  for  the  simulation  program  is  as  follows: 


Executive 

8,000 

SIMSCRIPT  subroutines 

7,500 

Model  program 
Definitions 

2,200 

Logical  subroutines 

12,500 

Reports 

5,800 

Available  for  data 

29,000 

65,000 

The  29,000  words  of  storage  available  for  data  may  be  further  divided 
into  two  parts,  one  for  initialization  data  and  the  other  for  dynamic 
and  working  data.  The  amount  of  storage  required  for  initialization 
data  depends  largely  upon  the  following  four  factors: 

T  Number  of  tasks  in  task  networks 
A  Average  number  of  resources  per  task 
R  Number  of  different  resources 

C  Number  of  columns  on  Performance  Summary  Report 

Based  upon  these  factors,  the  following  formula  may  be  used  to 
estimate  memory  requirements  for  initialization  data: 

Initial  Data  (5.55  +  A)  T+6.75R+71C+  1000. 

The  use  of  this  formula  may  be  illustrated  by  an  example.  Sup¬ 
pose  that  there  are  1000  tasks,  each  requiring  three  types  of  resources 
on  an  average.  Suppose  further  that  there  are  500  different  kinds  of 
resources  altogether  and  that  there  are  10  columns  specified  for  the 
Performance  Summary  Report.  Inserting  these  values  in  the  formula, 
the  following  results  are  obtained: 
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Initial  Data  2.  (5.55  +  3)(1000)  +  (6.75)(500)  +  (71)(10)  +  1000 
*  8,550  +  3,375  +  710  +  1000 
1  13,635 

Using  this  result,  about  15,400  words  of  memory  would  be  left  for 
dynamic  storage  requirements  and  working  space,  plus  2500  words  that 
become  available  after  Che  Initial  data  are  established.  This  would 
probably  be  sufficient,  but  whether  or  not  It  la  enough  cannot  be 
determined  in  advance.  In  general,  this  kind  of  memory  requirement 
depends  upon  frequency  and  patterns  of  mission  requirements,  resource 
levels,  policy  parameters,  and  other  factors,  all  of  which  interrelate 
in  an  exceedingly  complex  fashion  in  determining  how  much  storage  is  needed. 

From  this  analysis,  it  can  be  seen  that  the  maximum  size  problem 
that  can  be  run  on  a  given  computer  cannot  be  precisely  established 
in  advance.  As  indicated  by  Che  formula  for  initialization  data 
memory  requirements,  there  are  tradeoffs  among  the  four  main  factors 
involved.  However,  the  formula  and  judgments  concerning  dynamic 
storage  requirements  may  be  used  to  estimate  whether  or  not  a  given 
problem  will  fit  on  the  computer.  The  formula,  however.  Is  only 
valid  for  the  UNIVAC  1107  due  to  the  way  data  are  packed;  it  must  be 
appropriately  altered  for  any  other  computer  type. 

RUSHING  TIMES 

The  computer  time  required  to  run  the  L-COM  model  depends,  of 
course,  upon  the  size  of  problem  and  type  of  computer  used.  For  the 
UNIVAC  1107,  we  have  gained  sufficient  experience  to  estimate  run¬ 
ning  times  for  various  size  problems.  The  most  useful  factor  for 
estimating  simulation  running  ti-ies  is  the  number  of  tasks  that  are 
simulated  per  minute  of  computer  time.  This  factor  generally  lies 
between  800  and  1000  tasks  per  minute,  depending  upon  how  much  back¬ 
ordering  occurs  due  to  resource  scarcities.  With  this  factor,  esti¬ 
mates  may  be  made  of  running  times  for  various  flying  programs . 

As  an  example,  assume  that  a  four-squadron  base  is  simulated, 
each  squadron  having  18  airplanes  that  average  one  sortie  per  air¬ 
plane  per  day.  Assume  further  that  task  networks  are  defined  such 
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that  20  different  taske  ere  averaged  per  sortie.  Thus,  about  1540 
tasks  per  day  at  the  base  would  be  simulated;  using  the  above  plan¬ 
ning  factor,  a  day’s  worth  of  operations  would  therefore  take  1-1/2 
to  2  minutes  of  computer  time.  For  this  example,  we  might  generalize 
that  to  simulate  operatlone  of  a  full  base  with  a  reasonable  level 
of  detail  and  with  a  standard  flying  program  would  require  somewhere 
between  45  and  60  minutes  of  computer  time  for  the  UNIVAC  1107  for 
thirty  days  of  simulation. 

Extrapolating  this  to  other  examples,  however,  is  quite  hazardous. 
But  if  an  estimate  can  somehow  be  made  about  the  average  number  of 
dally  tasks  at  base,  the  planning  factor  of  800  to  1000  tasks  per 
minute  of  simulation  may  be  used  to  estimate  total  running  time  for 
a  UNIVAC  1107  or  other  machine  of  equivalent  speed. 

In  addition  to  running  times  for  the  main  simulation  program, 
the  preprocessor  and  postprocessor  also  require  time  to  run.  Although 
these  running  times  depend  upon  how  large  the  data  base  is  and  how 
much  processing  is  done,  estimates  for  maximum  running  times  can  be 
suds  from  previous  experience.  For  a  data  base  large  enough  to 
approach  the  capacity  limit  of  the  computer,  the  preprocessor  re¬ 
quires  sbout  20  minutes;  s  typical  mix  of  postprocessor  outputs  re¬ 
quires  about  10  minutes.  Again,  thesa  figures  pertain  to  the  UNIVAC 
1107  running  times  and  must  be  correspondingly  adjusted  if  another 
type  of  computer  is  considered. 

TRANSFER  TO  CTREE  COMPUTERS 

As  previously  mentioned,  the  Logistics  Composite  Model  is  now 
operating  on  the  UNIVAC  1107  at  Wrlght-Patterson  Air  Force  Base,  Ohio. 
If  another  type  of  computer  were  to  be  used,  a  SIMSCRIPT  compiler 
would  have  to  be  available  for  that  type  of  computer.  Fortunately, 
such  compilers  are  available  (or  about  to  beccne  available)  for  prac¬ 
tically  all  computers  large  enough  to  handle  the  model  described  here. 

At  present,  there  are  two  versions  of  SIMSCRIPT:  I  and  1.5.  If 
the  model  were  transferred  to  a  computer  that  has  a  SIMSCRIPT  1.5 
compiler,  little  difficulty  vould  be  encountered  in  the  conversion. 


There  are  two  shore  machine  language  routines  in  the  preprocessor 
which  allow  for  Che  variable  format  of  entries  on  the  input  forms. 
Essentially,  a  programmer  would  need  a  few  days  to  rewrite  these 
programs,  change  control  cards,  and  make  other  minor  adjustments 
necessary  for  operation  on  the  new  type  of  computer.  If  only  a 
SIMSCRIPT  I  compiler  were  available,  the  conversion  time  would  be 
somewhat  greater,  since  a  number  of  program  changes  would  be  needed, 
particularly  in  Che  preprocessor  and  postprocessor.  Altogether, 
several  weeks  of  programming  effort  would  be  needed. 


VIII.  MODEL  VALIDATION 


A  valid  simulation  model  requires  a  structure  that  adequately 
represents  the  environment  so  that  results  will  be  consistent  with 
those  of  the  real  world.  This  section  discusses  verification  and 
validation  procedures  for  the  Logistics  Composite  model. 

VALIDATION  REQUIREMENTS 

Since  it  is  Impossible  to  rapture  all  real-world  operations  in  a 
simulation  model,  various  abstractions,  simplifications,  and  omissions 
must  be  made.  These  compromises  are  reflected  in  both  the  input  data 
and  the  structure  of  the  model  itself.  In  using  the  model  to  investi¬ 
gate  system  behavior,  the  user  must  be  sure  that  the  compromises  he 
makes  can  be  explained  and  do  not  significantly  affect  the  resulta. 
Without  making  such  allowances  in  interpreting  results,  any  conclu¬ 
sions  derived  would  be  suspect.  A  variety  of  techniques  have  been 
developed  for  accomplishing  tha  model  verification  and  validation 

,  A 

functions . 

With  respect  to  verification  requirements,  the  Logistics  Com¬ 
posite  Model  is  somewhat  unique  in  that  most  of  the  structure  of  the 
environment  is  represented  in  input  data  the  user  provides .  In  con¬ 
structing  task  networks,  the  user  has  direct  control  over  what  portions 
of  the  base  environment  are  included  in  the  simulation  and  the  level 
of  detail  in  which  they  are  to  be  represented.  To  this  extent,  the 
verification  requirement  becomes  the  user's  responsibility .  He  must 
satisfy  himself  that  he  has  captured  as  much  of  the  environment,  in 
terms  of  scope  and  detail,  as  is  consistent  with  his  study  objectives. 
This  may  be  accomplished,  in  general,  by  modifying  and  adjusting  task 
network  and  other  data  until  results  are  obtained  that  are  acceptable 
for  his  objectives. 


A  discussion  of  such  techniques  is  contained  in  G.  S.  Fishman 
and  P.  J.  Kiviat,  Digital  Computer  Simulation:  Statistical  Considera¬ 
tions  ,  The  RAND  Corporation,  RM-5387-PR,  November  1967. 
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In  addition,  there  are  significant  features  of  real-vorld  opera¬ 
tions  that  the  current  version  of  the  model  does  not  allow  for;  some 
of  these  features  are  identified  in  Sec.  IX  for  inclusion  in  later 
versions.  The  omission  of  these  features  can  significantly  affect 
results  and  must  be  considered  or  compensated  for  in  interpreting 
the  results.  Because  of  these  omissions,  model  results  must  be  appro¬ 
priately  tempered  and  qualified. 

Insofar  as  validation  of  the  model  is  concerned,  the  main  cri¬ 
terion  is  being  able  to  reproduce  corresponding  measures  obtained 
from  real-world  experience  and/or  to  explain  satisfactorily  any  dif¬ 
ferences  that  might  exist.  The  largest  problem  in  this  procedure  is 
to  determine  the  proper  level  of  detail  necessary  to  satisfy  the 
validation  criterion.  In  constructing  task  networks  with  associated 
resource  definitions,  it  is  desirable  to  minimize  the  number  of  dif¬ 
ferent  kinds  of  tasks  in  order  to  conserve  computation  time  and  memory 
requirements;  however,  the  validation  criterion  car.not  be  satisfied 
if  task  representations  are  too  highly  abstracted.  There  is  no  easy 
solution  to  this  problem,  and  recou~se  must  normally  be  taken  to  trial 
and  error  proc  dures  tempered  by  Judgment  and  experience. 

USE  OF  PROJECT  PACE ~  SORT  DATA 

To  validate  the  Logistics  Composite  Model,  we  plan  to  use  expe¬ 
rience  aud  data  obtained  from  the  field  test  portion  of  the  PACER  SORT 
project.  A  comprehensive  data  collection  effort  included  in  the  field 
test  facilitates  its  use  for  this  purpose. 

For  the  validation,  the  actual  flying  program  experience  of  the 
field  test  will  be  input  to  the  model.  Task  networks  for  the  aircraft 
and  major  components  included  in  the  test  have  been  constructed.  Re¬ 
source  levels  will  be  input  according  to  those  established  in  the 
test.  In  general,  as  much  of  the  field  test  environment  as  is  prac¬ 
tical  will  be  represented  in  the  inputs.  With  this  data,  the  main 
validation  objective  will  be  to  determine  how  well  the  model  results 
compare  with  those  experienced  in  the  field  test. 

For  use  in  the  model,  task  networks  for  the  F-4C  aircraft  and 
major  components  have  been  developed.  Approximately  80  subnetworks 
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like  that  in  Fig.  28  have  been  established,  containing  1700  different 

tasks.  Associated  with  these  are  503  different  kinds  of  resources, 

[ 

broken  down  as  follows: 


Aircraft 

types 

4 

Personnel 

types 

21 

AGE  items 

128 

Reparable 

components 

350 

The  four  aircraft  types  are  used  to  represent  the  four  squadrons  of 
F-4C  aircraft  included  in  the  test.  The  350  reparable  components  and 
associated  personnel  and  AGE  items  were  selected  because  they  account 
for  most  of  the  maintenance  accomplished  during  the  test;  these  items 
either  have  relatively  high  failure  rates  or  require  extensive  repair 
when  they  fail.  With  these  data,  a  number  of  model  runs  will  be  made 
for  validation  purposes. 

In  general,  validation  requirements  will  be  considered  largely 
met  if  the  model  produces  results  matching  those  experienced  in  the 
field  teat  for  the  following  critical  performance  measures: 

Percentage  sorties  accomplished 

Average  aircraft  turnaround  time 

Average  maintenance  manhours  per  flying  hour 

Personnel  utilization  percentage 

ACE  utilization  percentage 

Not-operatlonally-ready  supply  (NOR S)  rate. 

If  the  model  produces  comparable  results  for  all  these  measures  simul¬ 
taneously,  there  will  be  considerable  assurance  that  functional  inter¬ 
actions  in  the  simulation  resemble  those  of  the  real  world.  If  there 
are  significant  differences  in  one  or  none  of  these  measures,  however, 
explanations  must  be  sought,  either  in  the  content  of  the  Input  data 
or  in  the  structure  of  the  model,  particularly  insofar  as  omitted 
features  might  be  involved. 

As  part  of  validation,  the  task  network  descriptions  are  subject 
to  considerable  change  because  of  Intermediate  model  results.  In 
general,  these  changes  involve  variations  in  task  arrangements  and 
the  addition  of  certain  tasks  to  more  fully  account  for  utilization 
of  available  resources.  Also,  factors  such  as  task  durations,  failure 
data,  and  stock  levels  are  being  refined  during  the  validation  process. 
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Fig.  28  --  Example  network  data  for  F-4C  radio  navigation  system 
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In  moat  cases,  these  changes,  extensions,  and  refinements  are  made  to 
correct  original  deficiencies  in  the  data  base  as  found  during  the 
validation.  Since  the  structure  of  the  simulated  environment  is 
largely  specified  by  the  input  data,  the  iterative  procedure  of  alter¬ 
ing  the  structure  to  improve  intermediate  results  of  the  validation 
criteria  represents  a  somewhat  unique  approach  to  validation.  Despite 
this  kind  of  flexibility,  however,  it  is  expected  that  results  based 
upon  PACER  SORT  experience  will  not  fully  satisfy  validation  require¬ 
ments  due  to  omissions  of  certain  real-world  features  in  the  model's 
structure . 

Another  limitation  of  the  validation  is  the  extent  to  which  data 
collected  during  the  field  test  adequately  represent  the  actual  en¬ 
vironment.  For  example,  if  the  data  misrepresent  the  supply  avail¬ 
ability  that  actually  existed,  then  validation  discrepancies  could 
occur  for  supply  performance  measures,  even  though  the  model  correctly 
replicates  the  true  performance.  In  validating  the  model,  therefore. 
Judgments  must  be  made  concerning  the  overall  adequacy  and  accuracy 
of  Che  reported  field  test  results  which  the  model  results  are  com¬ 
pared  against. 

In  view  of  these  limitations  and  others,  only  broad  validation 
objectives  can  be  achieved  from  Project  PACER  SORT  experience.  At  the 
very  least,  however,  these  objectives  include  indications  that  model 
results  are  not  nonsensical,  that  they  are  internally  consistent  among 
the  logistics  functions,  and  that  they  are  reasonable  approximations 
of  the  experienced  activity.  At  later  times,  the  model  may  be  further 
validated  with  other  sets  of  data. 

VALIDATION  RESULTS 

Preliminary  validation  results  based  upon  Project  PACER  SORT 
experience  indicate  that  broad  validation  objectives  for  the  L-COM 
model  can  be  satisfied.  The  extent  to  which  they  are  satisfied,  how¬ 
ever,  will  depend  upon  final  results.  When  the  validation  program  is 
completed,  a  separate  report  is  planned  describing  the  program  and 
results  in  further  detail. 
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IX.  FUTURE  EXTENSIONS  AND  APPLICATIONS 


The  Logistics  Composite  Model  described  here  is  the  initial  version 
(MOD  1)  that  is  currently  programmed  and  operating.  It  has  several 
limitations  that  either  constrain  the  scope  of  its  application  or  fail 
to  capture  and  represent  features  of  the  simulated  environment.  Several 
extensions  and  refinements  are  planned  to  alleviate  these  limitations. 
They  are  discussed  in  this  section. 

STRUCTURE  OF  FUTURE  VERSIONS 

In  the  future,  we  plan  to  expand  the  overall  structure  of  the 
model  to  include  two  new  major  features — a  repair  level  decision  model 
and  a  data  bank.  Figure  29  illustrates  how  these  components  will 
relate  to  the  current  version  of  the  model. 

The  main  function  of  the  repair  level  decision  model  is  to  select, 
from  the  many  thousands  of  parts  and  other  resources  involved  in  the 
support  of  a  weapon  system,  those  to  include  In  the  simulation  process. 
Resources  having  the  most  impact  upon  weapon  system  performance  will 
be  selected  for  detailed  representation  in  the  simulation;  remaining 
resources  will  be  aggregated  and  abstracted. 

The  data  bank  will  accrue  a  reservoir  of  input  data  such  as  infor¬ 
mation  on  a  number  of  weapon  systems,  operating  environments,  and  other 
factors.  This  will  be  stored  in  a  large  volume  memory  device,  such  as 
a  disk  unit  cr  a  drum,  so  that  data  needed  for  a  particular  applica¬ 
tion  of  the  model  can  be  readily  extracted. 

In  addition  to  these  new  elements,  extensions  and  refinements  in 
the  main  simulation  programs  and  embedded  decision  model  are  planned 
in  order  to  increase  the  validity  of  the  results  by  more  adequately 
representing  the  environment  and  decision  processes  included  in  the 
simulation . 

Some  of  the  new  features  of  the  model  may  be  inserted  in  the  ver¬ 
sion  now  operating.  Others,  however,  must  await  the  availability  of 
a  computer  with  a  larger  capacity  and  computing  power  than  the  one 
currently  being  used. 
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REPAIR  LE'/EL  DECISION  MODEL 

A  weapon  system  consists  of  thousands  of  parts  and  is  supported 
by  hundreds  of  different  kinds  of  resources  such  as  maintenance  per¬ 
sonnel  of  various  skills,  ground  support  equipment,  facilities,  and 
so  on.  Because  of  computer  limitations,  it  is  impossible  to  represent 
all  of  these  resources  and  their  interactions  in  the  simulation  of 
operations,  maintenance  and  supply  functions.  Actually,  it  is  seldom 
necessary  to  Include  all  of  this  information  since  some  of  it  does 
not  significantly  contribute  to  the  accuracy  of  the  results.  The 
problem  is  choosing  which  portions  of  the  weapon  system  and  supporting 
environment  to  represent  in  some  detail  and  which  to  abstract  or  omit 
altogether. 

Another  problem  concerns  which  repair  policy  to  assume.  A  par¬ 
ticular  repair  policy  must  be  prescribed  to  operate  the  model.  The 
policy  affects  the  factors  assigned  for  task  selection  and  the  con¬ 
struction  of  the  task  network.  For  an  existing  weapon  system,  a 
repair  policy  has  already  been  established  and  task  networks  can  be 
constructed  to  reflect  this  policy.  If  it  is  desired  to  investigate 
postulated  alternatives  to  the  established  repair  policy,  the  network 
can  be  correspondingly  changed  and  the  simulation  model  can  be  used 
to  evaluate  the  consequences.  For  a  new  weapon  system,  however, 
determining  an  appropriate  repair  policy  might  be  a  major  study  ob¬ 
jective.  For  both  existing  and  new  weapon  systems,  it  might  be  desired 
to  find  a  preferred  or  best  repair  policy  under  a  number  of  constraints 
and  to  then  evaluate  this  policy  by  simulation.  Determining  this 
policy  and  the  corresponding  task  network  needed  for  input  to  the 
simulation  represents  a  significant  problem. 

The  repair  level  decision  model  represents  an  analytic  approach 
designed  to  help  solve  these  problems.  As  input  data,  the  hierarchical 
structure  of  the  weapon  system  is  described,  both  in  terms  of  the 
physical  breakdown  of  included  parts  and  '□  terms  of  steps  taken  to 
isolate  faults  that  might  occur.  Also  input  are  reliability  factors 
for  included  parts  and  various  cost  factors  relating  to  repair  and 
supply  functions  involved  in  weapon  system  support.  Based  upon  these 


-90- 


data,  Che  model  evaluates  possible  combinations  of  repair  actions 
that  might  be  taken  when  a  particular  item  fails,  and  determines  the 
combination  which  will  minimize  expected  overall  support  costs.  As 
outputs,  the  model  specifies  whether  or  not  an  item  should  be  repaired 
when  it  fails  and,  if  repaired,  whether  it  should  be  done  by  organiza¬ 
tional  (flight-line)  maintenance,  base  repair  shops,  or  depot  repair 
facilities.  As  a  by-product  of  this  decision  process,  the  model  also 
determines  and  generates  the  requirements  for  maintenance  personnel, 
supply  levels  and  AGE  items  that  correspond  to  the  least-cost  repair 
level  decisions. 

This  model  identifies  the  items  contributing  most  to  the  total 
expected  support  cost.  For  a  typical  weapon  system,  a  few  hundred 
items  account  for  almost  all  of  the  repair  and  supply  support  costs 
that  are  inci’^red.  Once  the  initial  range  model  identifies  the 
troublesome  parts,  they  can  be  explicitly  represented  in  the  simula¬ 
tion,  with  the  remaining  items  being  represented  in  aggregate  form. 

Also,  the  repair  level  decisions  made  by  the  initial  range  model 
enable  corresponding  task  networks  to  be  developed  for  use  in  the 
simulation. 

The  repair  level  decision  model  may  be  used  independently  to  analyze 
and  determine  preferred  repair  policies  for  weapon  systems.  However, 
results  are  based  upon  minimizing  expected  values  of  future  costs  a» 
in  obtaining  these  results,  a  variety  of  operational  factors  are  n 
considered.  For  example,  the  effects  of  dynamic  flying  programs ;  .ie 
use  of  substitute  items,  cannibalization  practices,  task  preem  j.on, 
and  other  aspects  of  the  operational  environment  are  not  represented 
in  the  model  logic.  For  this  reason,  the  simulation  model  which 
recognizes  these  factors  is  used  to  evaluate  and  further  refine  deci¬ 
sions  produced  by  the  initial  range  model.  In  general,  the  initial 
range  and  simulation  models  are  designed  to  complement  and  reinforce 
each  other  in  determining  preferred  support  systems. 

Experimental  versions  of  the  repair  level  decision  model  have 
been  constructed  and  are  being  tested.  At  an  appropriate  point  in  its 
development,  the  program  will  be  incorporated  aa  an  integral  part  of 


Che  overall  L-COM  model  as  suggested  above.  A  separate  report  des¬ 
cribing  the  repair  level  decision  model  and  its  use  is  planned. 

ADDITIONAL  SIMULATION  FEATURES 

Several  additions  to  the  simulation  portions  of  the  L-CCM  model 
are  possible  to  represent  certain  features  of  the  operational  environ¬ 
ment.  Some  of  these  are  as  follows: 

1.  Conflicting  Maintenance .  Although  the  task  network  can  be 
used  to  identify  aircraft  maintenance  processes  that  can  be  accom¬ 
plished  simultaneously,  conflicting  maintenance  constraints  upon 
parallel  tasks  exist  which  depend  upon  the  particular  tasks  selected. 
Since  tasks  are  selected  randomly,  the  constraints  cannot  be  reflected 
in  the  task  network  as  currently  defined.  The  constraints  are  of  two 
main  types. 

One  type  is  a  physical  limit  on  the  number  or  type  of  resources 
used  by  several  tasks  occurring  simultaneously.  An  example  might  be 
several  casks  that  involve  work  in  the  airplane's  cockpit.  Since  the 
working  space  is  extremely  limited,  only  one  or  two  technicians  can 
be  employed,  and  the  required  tasks  must  be  accomplished  sequentially 
rather  than  in  parallel. 

Another  type  of  conflicting  maintenance  is  a  functional  one  where 
two  tasks  performed  simultaneously  might  create  a  hazardous  situation. 

A  typical  example  is  where  work  must  be  done  on  the  fuel  tanks  and 
the  electrical  power  system  of  an  airplane.  Both  tasks  cannot  be  done 
at  the  same  time  because  an  electrical  spark  might  couch  off  a  fuel 
explosion.  These  tasks  must  therefore  be  done  in  sequence,  although 
which  is  done  first  is  Immaterial. 

Including  these  constraints  in  the  simulation  will  more  realisti¬ 
cally  represent  actual  maintenance  practices,  as  well  as  improve  accuracy 
of  results  such  as  aircraft  turnaround  times  and  personnel  utilization 
rates . 

2.  Shop  Cannibalization.  In  the  current  version  of  the  simula¬ 
tion  model,  cannibalization  is  represented  only  to  the  extent  that 
needed  parts  are  borrowed  from  other  airplanes  that  are  in  maintenance. 
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Another  level  of  cannibalization  consists  of  borrowing  needed  parts 
from  other  components  or  assemblies  awaiting  repair  in  the  base  re¬ 
pair  shops.  Such  cannibalization  may  e\ in  extend  to  the  borrowing  of 
parts  from  test  equipment  or  from  serviceable  higher  assemblies  in 
base  supply.  In  some  cases,  this  type  of  cannibalization  can  sig¬ 
nificantly  affect  system  performance.  When  this  feature  is  included 
in  the  simulation,  the  effects  and  consequences  can  be  measured. 

3.  Item  Criticality .  When  certain  items  fail  and  cannot  be  re¬ 
placed  due  to  lack  of  spares,  sometimes  the  airplane  can  still  be 
used  for  some  types  of  missions.  For  example,  a  malfunction  of  the 
fire  control  system  might  not  prevent  using  an  airplane  for  a  cross¬ 
country  training  flight.  Other  item  failures,  such  as  in  the  com¬ 
munications  system,  may  ground  the  airplane  until  the  malfunction  is 
corrected. 

In  the  current  model,  all  items  are  considered  critical  in  the 
sense  that  their  failure  will  prevent  further  use  of  the  airplane 
until  fixed.  Adding  item  criticality  considerations  to  the  model  will 
represent  deferred  maintenance  and  will  produce  more  accurate  results 
with  respect  to  mission  performance. 

4.  Weather  Effects.  Weather  very  often  has  an  important  effect 
upon  base  operations.  Airplanes  may  be  prepared  for  a  mission  and 
then  be  unable  to  take  off  because  of  adverse  weather  at  the  base  or 
in  the  target  area,  in  the  current  model,  weather  effects  can  only 
be  implicitly  considered  by  the  way  in  which  mission  requirements  are 
generated.  A  more  explicit  representation  will  enable  the  impact  of 
weather  factors  upon  overall  base  operations  to  be  measured  and  analyzed. 

5.  Multibase.  The  current  L-COM  model  only  considers  aircraft 
operations  at  one  base.  Actually,  the  definition  of  a  base  in  this 
context  is  somewhat  ambiguous.  Insofar  as  the  operation  of  the  model 
is  concerned,  a  base  consists  of  any  common  pool  of  resources  sup¬ 
porting  tasks ,  defined  by  a  task  network,  generated  in  accordance  with 
mission  requirements.  Although  this  description  fits  that  of  an  or¬ 
dinary  base,  it  may  also  pertain  to  more  unusual  situations  such  as 
certain  types  of  dispersed  operations . 

Later  versions  of  the  model  may  include  explicit  recognition  of 
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aircraft  operations  at  a  number  of  bases  simultaneously.  When  this 
feature  is  added,  certain  interactions  can  be  represented.  For  example, 
several  kinds  of  lateral  support  can  be  simulated,  where  one  base 
provides  needed  resources  to  another.  As  another  example,  procedures 
for  allocating  mission  requirements  among  bases  according  to  their 
aircraft  availability  may  be  Inserted  in  the  simulation.  Transporta¬ 
tion  functions  and  base-depot  interactions  can  be  better  represented 
in  a  multi-base  simulator. 

Although  there  appear  to  be  no  difficult  conceptual  problems  in¬ 
volved  in  extending  the  model  to  the  multibase  situation,  significant 
computation  and  machine  capacity  problems  may  occur.  Unless  the  num¬ 
ber  of  resources  snd  the  sl2e  of  the  task  network  are  severely  cur¬ 
tailed,  a  multibase  simulation  will  require  a  considerably  larger  and 
faster  computer  than  the  one  currently  being  used. 

DECISION  MODEL  REFINEMENTS 

The  forecasting  procedure  and  decision  model  currently  Included 
as  subroutines  in  the  L-COM  model  are  relatively  crude  and  subject  to 
refinement  in  later  versions.  Since  the  forecasting  procedure  is  based 
upon  an  exponential  smoothing  technique,  it  can  react  only  to  past  data 
observed  in  the  simulation.  For  sudden  changes  in  the  flying  program, 
it  often  reacts  too  late  If  the  smoothing  constant  were  raised  to 
increase  the  response  time ,  the  procedure  would  overreact  to  random 
fluctuations  in  the  performance  measure.  For  these  reasons  snd  others, 
a  better  forecasting  procedure,  perhaps  one  using  some  kind  of  regres¬ 
sion  technique  based  upon  future  flying  programs,  may  be  developed 
and  applied  in  place  of  the  present  procedure. 

The  decision  model  is  also  subject  to  considerable  improvement. 
Preliminary  experience  shows  that  the  way  in  which  the  utilization 
index  is  defined  is  not  completely  satisfactory,  and  some  better 
measure  for  resource  posture  relative  to  requirement  may  be  developed. 
Also,  in  considering  different  times  for  augmentation ,  the  model  assumes 
that  they  all  have  equal  impact  upon  the  performance  measure  being 
used.  Since  this  is  not  usually  true,  some  way  to  reflect  the 


difference  might  be  developed,  perhaps  based  upon  the  remoteness  of 
the  resource  from  the  airplane  in  its  use . 

Another  major  deficiency  is  that  the  decision  model  only  in¬ 
creases  resource  levels  and  does  not  decrease  them.  Thus,  it  does 
not  recognize  and  appropriately  reduce  surpluses  that  might  occur. 

If  this  deficiency  is  corrected  and  the  simulation  extended  to  a 
multibase  environment,  the  decision  model  may  then  be  used  to  allo¬ 
cate  resources  among  the  various  bases  effectively. 

DATA  BANK 

The  development  of  data  required  for  input  to  the  Logistics 
Composite  Model,  particularly  that  pertaining  to  the  task  networks, 
is  not  a  very  easy  job.  Once  developed  for  a  particular  weapon  sys¬ 
tem  or  aircraft  type,  however,  the  data  may  be  used  for  a  variety  of 
studies.  As  the  model  is  applied  to  different  weapon  systems  and 
operating  environments,  it  is  envisioned  that  the  corresponding  data 
might  be  accumulated  in  a  systematic  fashion  into  a  data  bank  from 
which  information  needed  for  a  particular  study  could  be  readily 
extracted . 

Such  a  data  bank  might  include  the  following  classes  of  informa¬ 
tion  : 

1.  Flying  programs  for  possible  contingency  deployments 

2.  Task  networks  and  associated  data,  in  several  levels 
of  detail,  for  various  types  of  weapon  systems  and 
repair  policies 

3.  Factors  for  alternative  resource  leveling  procedures 
and  shift  policies 

If  a  data  bank  containing  this  type  of  information  in  machine- 
accessible  form  is  established,  it  might  be  possible  to  provide  a 

user  with  a  simple  check  list  or  questionnaire-type  form  for  specify- 

* 

ing  a  particular  simulation.  Thus,  he  might  identify  a  particular 


* 

A  similar  technique  is  used  in  A.  S.  Ginsberg,  H.  M.  Markowitz, 
and  P.  M.  Oldfather,  Prograrming  by  Questionnaire ,  The  RAND  Corpora¬ 
tion,  RM-4460-PR,  April  1965. 


type  of  flying  program,  a  generic  description  of  a  repair  policy  and 
task  network  for  a  particular  aircraft  type,  and  a  particular  pro¬ 
cedure  for  computing  resource  levels.  According  to  these  specifica¬ 
tions,  the  computer  could  then  extract  the  necessary  detailed  data 
from  the  data  bank  and  use  it  for  the  simulation. 

From  a  programming  point  of  view,  the  data  bank  concept  would 
have  its  main  Impact  in  the  preprocessor  functions.  In  general,  the 
preprocessor  as  currently  developed  would  be  replaced  by  an  informa¬ 
tion  retrieval  program  designed  to  extract  needed  data  from  the  data 
bank  according  to  user-provided  specifications. 

ON-LTNE  SIMULATION 

In  the  present  version  of  the  model,  a  user  must  wait  until  the 
entire  simulation  is  finished  before  he  can  view  the  results.  In  a 
later  development,  a  concept  of  on-line  simulation  may  be  applied 
wherein  a  user  may  see  results  as  they  generate  during  the  simulation. 
Furthermore,  methods  can  be  provided  for  enabling  a  user  to  Interact 
with  the  simulation  by  altering  certain  factors  according  to  Inter¬ 
mediate  results,  thereby  changing  the  direction  of  the  subsequent 
simulation.  For  example,  intermediate  results  may  Indicate  a  need 
for  altering  the  overtime  policy;  by  changing  the  relevant  parameters, 
the  user  can  alter  the  overtime  policy  in  subsequent  operation  of  the 
simulation.  Similarly,  this  feature  enables  a  user  to  experiment  with 
various  policy  parameters  wherein  Impacts  can  be  Immediately  discovered 
as  the  parameters  are  changed. 

For  the  on-line  mode  of  simulation,  visual  display  devices  such 
as  a  CRT  (cathode  ray  tube)  device  would  be  used.  Many  results  would 
be  presented  in  graphical  form  similar  to  those  the  postprocessor 
generates.  As  the  simulation  proceeds  in  the  computer,  the  graphs 
would  simultaneously  be  generated  and  displayed.  Procedures  would  be 
provided  for  rapidly  selecting  desired  displays  and  for  altering 
values  of  policy  parameters  or  other  portions  of  the  data  base.  When 
results  are  obtained  that  need  to  be  preserved,  copies  of  the  diaplays 
in  more  permanent  form  can  be  made. 


-96- 


This  concept,  when  Applied  to  the  Logiatice  Composite  Model, 
will  enable  a  uaer  to  view  the  overall  operation  of  a  baae  in  accel¬ 
erated  time.  Within  a  few  minutes,  several  dsya'  operations  can  be 
witnessed.  Functional  interactions,  resource  utilizations,  and  other 
aspects  of  the  operating  envlronaent  can  be  more  easily  identified. 

In  general,  on-line  simulation  can  constitute  a  valuable  technique 
for  use  in  a  variety  of  planning  studies. 

MAJOR  APPLICATIONS 

The  preceding  discussion  has  suggested  a  number  of  uses  and  appli¬ 
cation  areas  for  the  Logistic  Composite  Model.  There  are  still  two 
main  applications  of  special  importance,  particularly  with  respect  to 
the  use  of  advanced  versions.  One  is  the  determination  of  logistics 
requirements  in  support  of  contingency  operations ;  the  other  is  the 
determination  of  preferred  repair  policies  and  aasodated  resource 
requirements  for  new  weapon  systems. 

A  contingency  deployment  is  characterized  by  a  dynamic  flying 
program  which  heavily  stresses  the  supportive  logistics  system.  In 
many  cases,  as  many  sorties  as  possible  must  be  flown,  the  number 
being  limited  solely  by  the  ability  of  the  support  system  to  turn 
around  airplanes  after  each  sortie.  Determining  this  maximum  flying 
capability  and  the  associated  requirements  for  support  resources  con¬ 
stitute  an  important  but  difficult  problem.  The  problen  is  compounded 
by  the  madber  of  different  kinds  of  contingency  deployments  that  might 
be  considered  in  terms  of  operating  environment,  dynamic  factors  in¬ 
volved,  and  weapon  systems  used.  The  L-COM  model  is  particularly 
useful  in  studying  these  deployment  problems  because  it  permits  a 
full  representation  of  the  major  facets  of  the  overall  support  system 
Involved  and  their  Interactions  in  meeting  the  mission  requirements. 
Also,  the  decision  aspects  of  the  model  help  determine  the  resource 
posture  needed  to  best  support  the  deployment.  In  many  respects,  the 
use  of  the  model  provides  a  viable  alternative  to  the  field  tests  cr 
other,  less  accurate  analysis  techniques  that  might  otherwise  be  re¬ 
quired  for  such  purposes . 
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In  modem  weapon  system  design  philosophy,  logistics  support  is 
viewed  as  a  part  of  Che  overall  weapon  system,  materially  affecting 
the  design  of  the  weapon  itself.  Lifetime  support  costs  become  an 
important  ingredient  in  the  design  criteria,  where  many  components 
may  be  designed  that  have  higher  initial  costs  but  will  have  sig¬ 
nificantly  lower  subsequent  repair  and  supply  costs.  The  determina¬ 
tion  of  break-even  points  in  this  regard  is  a  difficult  problem  be¬ 
cause  of  the  functional  interactions  involved.  Repair  policies, 
supply  and  maintenance  personnel  requirements,  and  design  charac¬ 
teristics  of  ground  support  equipment  are  all  interrelated  in  this 
problem.  Advanced  versions  of  the  Logistics  Composite  Model  can  be¬ 
come  a  valuable  analysis  technique  for  these  kinds  of  problems. 

The  repair  level  decision  model,  as  previously  described,  can 
be  used  to  make  preliminary  determinations  of  a  preferred  support 
system  in  terms  of  repair  policies  and  associated  resource  require¬ 
ments.  These  initial  determinations  may  then  be  refined  by  using  the 
simulation  and  embedded  decision  models.  In  this  regard,  the  task 
network  concept  of  the  simulation  program  is  particularly  useful, 
since  it  enables  components  subject  to  design  review  to  be  represented 
in  necessary  levels  of  detail.  By  using  these  features  of  the  L-COM 
model  interactively  in  the  design  of  a  weapon  system,  tradeoffs  can 
be  analyzed,  leading  to  an  optimization  of  the  overall  weapon  system 
Including  logistics  support. 

Although  these  two  application  areas  are  identified  as  especially 
significant  insofar  as  future  use  of  the  L-COM  model  is  concerned, 
there  are  many  other  study  areas  and  problems  in  which  the  model  can 
serve  a  role.  In  general,  any  problem  involving  significant  inter¬ 
actions  among  the  many  functions  accomplished  at  an  Air  Force  base 
can  be  analyzed  by  this  technique. 
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Appendix 

GLOSSARY  OF  DATA  ELEMENTS 

This  Appendix  lists  and  defines  the  data  elements  included  in 
user-provided  input  forms  for  the  Logistics  Composite  Model.  The 
data  elements  are  grouped  according  to  the  following  forms: 


Form  Number 

Title 

1 

Run  Specifications 

10 

Performance  Summary  Report  Specifications 

11 

Task  Network 

12 

Task  Definitions 

13 

Resource  Definitions 

14 

Failure  Clock  Decrements 

15 

Distributions 

16 

Shift  Change  Policy 

17 

Mission  Entry  Points 

20 

Sortie  Generation  Data 

In  addition  to  the  listed  data  elements,  each  line  on  the  forms  con¬ 
tains  a  preprinted  card  number  that  identifies  the  corresponding  data 
when  converted  to  punched  card  form. 

The  above  list  includes  all  input  forms  required  by  the  model 
except  for  Form  18  (Priority  Specifications) ,  Form  30  (Forecast  Param¬ 
eters  Specifications)  ,  and  Form  40  (Decision  Model  Factors) .  Data 
elements  on  these  two  forms  are  excluded  from  this  Appendix  because 
they  are  defined  on  the  forms  themselves. 

FORM  1— RUN  SPECIFICATIONS 

Model  Selection  An  "X"  mark  in  the  indicated  space  that  causes 

the  forecasting  procedure  and/or  the  decision 
model  to  operate. 

Report  Selection  Entering  simulation  times  in  the  spaces  provided 

causes  production  of  the  associated  special  re¬ 
ports  at  certain  times. 


FORM  10— PERFORMANCE  SUMMARY 


Reporting  Cycle 


The  time  between  successive  productions  of  the 
Performance  Summary  Report,  Level  I. 
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N umber  Of  Cycles  The  number  of  Level  I  reporting  cycles  before 

Level  II  of  the  Performance  Sunsnary  Report  is 
produced. 

Number  Of  Groups  The  number  of  columns,  for  respective  parts  of 
(Categories)  the  Performance  Summary  Report,  in  which  summary 

statistics  are  to  be  displayed. 

Column  Headings  Labelings  to  appear  over  each  column  of  the  Per¬ 
formance  Susmary  Report  for  respective  parts  of 
the  Report. 

FORM  11— TASK  NETWORK 

Prior  Node  The  label  for  the  beginning  node  of  a  task  in  the 

task  network. 

Selection  Mode  A  code  identifying  and  controlling  whether  or  not 

the  task  will  be  incurred  when  encountered. 

Task  1.0.  A  label  identifying  the  task  in  the  task  network. 

Next  Node  The  label  for  the  ending  node  of  a  task  in  the 

task  network. 

Selection  Parameter  A  factor  representing  the  probability  of  selecting 

the  task  when  encountered. 

Task  Description  A  verbal  description  of  the  task. 

FORM  12-TASK  DEFINITIONS 

Task  l.D.  The  identification  of  the  task  as  established  on 

Pora  11. 

The  priority  code  assigned  to  the  task. 

The  length  of  time  a  task  will  last;  selected  as 
a  random  draw  from  a  probability  distribution  of 
the  specified  type,  with  a  mean  and  variance  as 
indicated . 

An  identification  of  the  major  resource  with 
which  the  task  is  associated. 

Resource  Rgrs  Identifications  of  the  kinds  and  quantities  of 

Resource  resources  needed  to  accomplish  the  task. 

Quantity 


FORM  13— RESOURCE  DEFINITIONS 

Resource  I.D.  The  identification  of  the  resource  as  established 

on  Form  13. 


Priority 

Task  Duration 
Mean 
Variance 

Distribution  Type 
Associated  Resource 


BEST  AVAILABLE  COPY 
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Resource  Type  A  code  identifying  the  type  of  resource  (air¬ 

craft,  personnel,  parts,  AGE,  facilities). 

Report  Column  The  column  in  the  Performance  Summary  Report  into 

which  statistics  for  the  resource  are  to  be  ac¬ 
cumulated. 


Unit  Cost 

Authorized  Quantity 
Substitute  Resource 


The  per  unit  acquisition  cost  of  the  resource. 

The  mmber  of  units  of  the  resource  authorized 
for  stockage. 

The  identification  of  c  substitute  resource  if 
any . 


FORM  14- FAILURE  CLOCK  DECREMENTS 


Task  I.D. 

Mode 

Resource  I.D. 
Decrement 


The  identification  of  the  task  with  which  resource 
failures  are  associated. 

A  code  identifying  the  failure  mode  (flying  hours, 
number  of  landings,  etc.)  for  associated  resources. 

For  each  task  causing  failures,  the  identifica¬ 
tion  of  associated  resources  subject  to  failure. 

For  each  resource  subject  to  failure,  the  amount 
by  which  its  failure  clock  is  reduced  each  time 
the  associated  task  is  incurred. 


FORM  15-DISTRIBUTIONS 


Distribution  I.D. 

Type 

Format 


The  identification  of  a  particular  probability 
distribution. 

A  code  for  type  of  distribution. 

A  code  for  format  of  the  distribution  data. 


Probability  The  discrete  or  cumulative  (depending  on  distri¬ 

bution  type)  probability  of  occurrence  for  tha 
corresponding  value. 

Value  The  value  of  a  variable  to  which  the  corresponding 

probability  applies. 


FORM  16-SHIFT  CHANGE  POLICY 

Code  A  code  identifying  the  type  of  data  entered  in 

the  corresponding  row. 


Resource  I.D. 


The  Identification  of  resources  subject  to  tha 
shift  policy. 
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Shift  Durations/ 
Authorized  Levels 


The  length  of  each  shift  (if  code  *  *) ,  the  num¬ 
ber  of  shift  cycles  (if  code  *  R) ,  or  the  author¬ 
ized  level  (if  code  *  blank). 


FORM  17— MISSION  ENTRY  POINTS 

Mission  I.D.  The  identification  of  the  mission  type. 

Report  Column  The  column  in  the  Performance  Summary  Report  into 

which  statistics  for  the  mission  type  are  to  be 
accumulated. 

Network  Entry  Point  The  identification  of  the  starting  node  in  the 

network  for  aircraft  assigned  to  the  mission. 


FORM  20— SORTIE  GENERATION  DATA 

Day  The  simulation  day  in  which  the  mission  is  to 

occur. 


Nunfcer  of  Missions  The  number  of  missions  of  the  same  type  to  be 

accomplished,  or  the  identification  of  a  prob¬ 
ability  distribution  from  which  the  number  is 
to  be  drawn. 

Takeoff  Time  The  takeoff  time  for  the  mission,  or  the  identi¬ 

fication  of  a  probability  distribution  from  which 
the  number  is  to  be  drawn. 


Aircraft  I.D. 


The  type  of  aircraft  required  for  the  mission. 


Mission  I.D. 


The  type  of  mission. 


Mission  Size 
Minimum 
Maximum 
Spare 


The  number  of  airplanes  needed  for  the  mission 
in  terms  of  a  minimum,  maximum,  and  number  of 
spares . 


Mission  Length 
Mean 

Variance 

Distribution  Type 


The  total  flight  time  for  the  mission  as  drawn 
from  a  distribution  of  the  indicated  type,  mean, 
and  variance. 


Lead  Time 


Cancel  Time 


Cycle 

Interval 

Stop 


The  time  prior  to  takeoff  needed  to  prepare  air¬ 
craft  for  the  mission. 

The  time  after  takeoff  time  at  which  a  mission 
is  canceled  if  required  aircraft  are  unavailable. 

The  time  interval  over  which  the  indicated  mis¬ 
sions  are  to  be  repeated  until  the  indicated 
stop  time  is  reached. 


BEST  AVAILABLE  COPY 
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